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


• 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.


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 konsisten dengan kebijakan dan etika

perusahaan, sesuai dengan norma dan etika kerja.

• Team work: berkoordinasi dan berinteraksi dengan karyawan atau unit lain

untuk meningkatkan efesiensi dan efektivitas aktivitas kerja.

40


• Trust: menjunjung tinggi kejujuran, ketulusan, dan keterbukaan dengan

memperhatikan prinsip kehati-hatian, serta menjaga kerahasiaan perusahaan.

• Innovation: menghasilkan ide-ide baru dan unik atau memulai sebuah gerakan

yang bersifat “outside the box” untuk meningkatkan proses, metode, sistem,

atau layanan.

• Customer oriented: menjamin terpenuhinya kebutuhan pelanggan,

memprioritaskan pelanggan sebagai pusat dari semua kegiatan operasional.

4.3 Produk dan Layanan

Asyst menyediakan layanan solusi TI secara menyeluruh bagi industri airline.

Layanan-layanan ini meliputi konsultasi, pengembangan, implementasi, solusi

untuk industri dan operasional. Secara umum Asyst membagi layanannya ke

dalam 4 jenis, yaitu:

1. Airline, transportation and travel solutions (ATTS)

Solusi ini didesain untuk mengintegrasikan seluruh bisnis proses airline.

Solusi ini merupakan kombinasi dari beberapa produk yaitu:

• Compass: Compass adalah kependekan dari computerized passenger

service solution dan adalah sebuah sebuah PSS (passenger service

system). Dengan demikian compass adalah sebuah sistem manajemen

penumpang yang lengkap dari sebuah airline. Beberapa kelebihan

compass antara lain: 1) tingkat ketersediaan yang tinggi diatas 99%; 2)

membutuhkan bandwith yang rendah; 3) respon yang cepat; dan 4) sesuai

dengan standar IATA. Saat ini compass berjalan di atas mesin

mainframe IBM Z10 dengan terminal klien yang sudah terhubung dengan

komunikasi TCP/IP. Compass sendiri terdiri dari beberapa modul besar

yaitu: 1) Reservasi; 2) Schedule and inventory; 3) Ticketing dan 4)

Departure control system (DCS).

• LIPS: LIPS adalah kependekan dari light integrated passenger system.

Pada dasarnya LIPS juga adalah sebuah PSS. Berbeda dengan compass

yang dapat menampung airline dengan skala besar, maka LIPS lebih

ditujukan untuk airline yang bersifat low cost carrier (LCC).

41


• IBE (Internet Booking Engine): IBE adalah layanan melalui internet

dalam suatu situs web yang membantu pelanggan untuk melakukan

booking terhadap suatu jadwal penerbangan.

• sMile: sMile adalah sebuah frequent flyer program. Dengan sMile

penumpang dari airline yang terdaftar sebagai anggota frequent

flyerprogram mempunyai kesempatan untuk mengakumulasi miles pada

saat bepergian dengan jasa airline. Nantinya miles yang terkumpul dapat

ditukarkan dengan tiket, mendapat upgrade dari ekonomi ke kelas bisnis

atapun award lain seperti promosi spesial tertentu.

• E-Briefing: solusi untuk proses briefing untuk cabin crew.

• Sales Dashboard: aplikasi yang dapat menampilkan secara visual dan

mengukur pencapaian penjualan, performa dan produktivitas dari sebuah

airline.

• Meals monitoring: meals monitoring adalah sebuah layanan untuk

manajemen perencanaan penyediaan makanan untuk industri transportasi.

• Flight monitoring: flight monitoring adalah sebuah solusi untuk

memonitor keberangkatan dan kedatangan untuk industri airline.

• CFD (Centralized Flight Dispatch): solusi untuk manajemen paket

perjalanan antara flight dispatcher dan pilot in command (PIC) secara

real-time.

• Revenue accounting: solusi untuk kontrol, pelaporan, penggunaan, dan

akunting terkait dengan informasi revenue dari airline.

• Cargo solutions: solusi untuk reservasi kargo.

2. Infrastructure hosting and managed services (IHMS)

Asyst juga menyediakan beberapa layanan yang terkait dengan infrastruktur

termasuk juga disalamnya layanan mainframe dan layanan hosting sebagai

berikut:

• Mainframe operating and hosting services: mainframe hosting dengan

end-to-end support. Layanan akan termasuk desain, perencanaan,

implementasi, transisi, dan operasional dari mainframe.

• Infrastructure hosting and managed service: Dalam hal ini Asyst

menyediakan layanan data center. Layanan yang diberikan meliputi

42


operasional, administrasi, dan juga maintenance. Dukungan yang

diberikan pada layanan ini meliputi sumber daya manusia dan juga

teknologi seperti penerapan virtualisasi, cloud computing dan tingkat

keamanan yang tinggi.

• Desktop and peripheral equipment: Asyst juga memberikan layanan

dalam penyediaan desktop termasuk peripheral equipment yang terkait

dengan operasional airline.

• Networking service: layanan network yang diberikan Asyst juga lebih

banyak terkait dengan aktivitas dari sebuah airline. Hal ini ditujukan

untuk menjamin ketersediaan network pada sebuah airport dan juga

ketersediaan network untuk aplikasi-aplikasi yang digunakan oleh sebuah

airline.

• Helpdesk and operation support: Dari sisi operasional Asyst memiliki

layanan helpdesk and operation support. Layanan yang diberikan oleh

helpdek berupa single point of contact dan dapat melalui telepon, e-mail,

SMS, chat, dan lain-lain dengan layanan 24 jam per hari.

3. System integration and software development (SISD)

• E-Learning system: sistem layanan e-learning yang disediakan

memungkinan pengunjung untuk memahami konten yang ada dengan

dukungan interaktif.

• Executive lounge: Asyst juga menyediakan layanan boarding information

di executive lounge.

• Open source software development: Asyst juga menyediakan layanan

untuk pengembangan sistem dengan solusi open source diantaranya

untuk pengembangan ERP.

• Mainframe system development: pengembangan solusi yang ada di

mainframe berbasiskan z/TPF, z/OS, z/VM, z/Linux, IMS, dan CICS.

• SAP ERP implementation: Implementasi SAP beserta modul-modulnya

seperti FICO, HR, dan lain-lain.

• Open source ERP implementationi: implementasi ERP dengan solusi

open source yaitu Adempiere dengan mengintegrasikan berbagai proses

yang terkait dengan ERP.

43


4. Business consultancy(BiCo)

• Consulting service: Asyst juga menyediakan layanan untuk konsultasi di

bidang TI terutama untuk penerapan TI seperti desain strategi TI, desain

keamanan TI dan konsultasi infrastruktur TI.


BAB 5

HASIL DAN PEMBAHASAN

Bab ini berisi tentang hasil dan pembahasan penelitian yang telah dilakukan.

Urutan penyajian pada bab ini disesuaikan dengan langkah-langkah yang telah

dibuat dalam metodologi penelitian. Pada bab ini dibahas hasil dari setiap tahap

penelitian sampai dengan hasil akhir penelitian.

5.1 Pendahuluan

Tahap pendahuluan adalah tahapan awal dari penelitian. Pada tahap ini

didefinisikan hal-hal seperti requirement of architecture work dan prinsip-prinsip

arsitektur yang akan mempengaruhi desain arsitektur.

5.1.1 Requirements for architecture work

Requirements for architecture work mencakup beberapa hal yaitu kebutuhan

bisnis, arahan organisasi dan aspirasi kultural. Berikut adalah penjabaran akan

hal-hal tersebut.

• Kebutuhan bisnis

Kebutuhan bisnis diperoleh dari hasil wawancara dengan CTO dengan

melihat kebutuhan-kebutuhan yang ada untuk pengembangan enterprise

architecture. Berikut adalah kebutuhan bisnis yang telah didefinisikan:

o Dapat memenuhi permintaan klien dengan cepat.

o Mengutamakan resource sharing dan pemanfaatan cloud computing agar

tercapai economies of scale.

o Arsitektur yang diutamakan adalah di level PSS (core systemuntuk

airline) dan aplikasi lain yang terkait langsung dengannya (mencakup

bisnis inti airline).

o 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.

45


o Desain arsitektur yang robust, menggunakan standar-standar teknologi

yang bersifat best practice standard.

o Memiliki fungsi kontrol dan monitoring yang memadai untuk

operasional.

o Desain arsitektur yang memenuhi standard policy dan complience yang

ada seperti IT security requirement.

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

• Arahan organisasi

Arahan organisasi adalah sejalan dengan visi organisasi yaitu menjadi nomor

satu sebagai penyedia layanan TI untuk industri transportasi dengan solusi TI

yang komprehensif, terkemuka, dan lengkap sedangkan untuk mencapai hal

tersebut didefinisikan misi perusahaan sebabagi berikut:

o Membawa nilai tambah bagi PT XYZ dan XYZ group

o Menyediakan layanan TI yang berkualitas dan efisien

o Menyediakan solusi TI dengan portofolio yang lengkap

• Aspirasi kultural

Aspirasi kultural disesuaikan dengan corporate culture yang ada di organisasi

yang disebut dengan Get IT Ondengan penjabarannya sebagai berikut:

o Integrity: bertindak dengan cara yang konsisten dengan kebijakan dan

etika perusahaan, sesuai dengan norma dan etika kerja.

o Team work: berkoordinasi dan berinteraksi dengan karyawan atau unit

lain untuk meningkatkan efisiensi dan efektivitas aktivitas kerja.

o Trust: menjunjung tinggi kejujuran, ketulusan, dan keterbukaan dengan

memperhatikan prinsip kehati-hatian, serta menjaga kerahasiaan

perusahaan.

o Innovation: menghasilkan ide-ide baru dan unik atau memulai sebuah

gerakan yang bersifat “outside the box” untuk meningkatkan proses,

metode, sistem, atau layanan.

o Customer oriented: menjamin terpenuhinya kebutuhan pelanggan,

memprioritaskan pelanggan sebagai pusat dari semua kegiatan

operasional.

46


5.1.2 Prinsip-prinsip arsitektur

Sebagai aturan dan panduan umum dalam pengembangan enterprise architecture,

maka perlu didefinisikan prinsip-prinsip arsitektur. Prinsip-prinsip arsitektur

disesuaikan dengan requirements of architecture work yang telah didefinisikan

agar organisasi dapat mencapai misi yang telah ditetapkan. Berikut adalah

prinsip-prinsip arsitektur yang ditetapkan beserta penjelasannya:

• Prinsip-prinsip bisnis

1. Design for change

Pernyataan: Aplikasi terbagi dalam layer-layer berbentuk multi-tier

sehingga perubahan pada satu layer tidak berefek ke dalam

layer yang lain

Dasar pemikiran: Prinsip design for change diterapkan agar aplikasi dapat

bersifat fleksibel terhadap perubahan. Secara bisnis hal ini

menguntungkan Asyst dikarenakan permintaan klien dapat

dipenuhi dengan cepat (faster time to market).

Implikasi: Menerapkan konsep layering dalam pengembangan

aplikasi. Pemanfaatan design pattern dapat dilakukan untuk

penerapan application layering.

2. Maximize agility and flexibility of application and Infrastructure

Pernyataan: Aplikasi dan infrastruktur yang ada dapat selalu memenuhi

tuntutan bisnis. Dapat dilakukan scaling dengan mudah

terhadap Aplikasi dan infrastruktur.

Dasar pemikiran: Dengan penerapan prinsip ini maka aplikasi dapat selalu

memenuhi tuntutan bisnis dari sisi scalability. Hal ini

penting dikarenakan seiring dengan waktu maka jumlah

pengguna aplikasi dapat selalu bertambah, hal ini terutama

untuk yang sifatnya berhubungan langsung dengan end

customer melalui jaringan internet. Dengan prinsip ini

maka aplikasi dan infrastrukturnya bersifat scalable

sehingga memaksimalkanagilitydan fleksibel terhadap

peningkatan bisnis.

Implikasi:

47


o Penerapan virtualisasi sebagai infrastruktur dari aplikasi

yang ada

o Aplikasi dikembangkan dengan kemampuan clustering

untuk menjamin peningkatan kapasitas dapat dilakukan

dengan mudah dan cepat.

3. Secure Information

Pernyataan: Pertukaran informasi bersifat secure terutama aliran

informasi yang melalui jalur publik

Dasar pemikiran: Saat ini keamanan informasi menjadi hal penting dan

hal tersebut juga mendasari stakeholder untuk memasukkan

unsur keamanan dalam architecture requirement. Secara

bisnis bagi Asyst hal ini menjadi faktor yang memperkuat

sisi bisnis dikarenakan data milik airline yang dikelola oleh

Asyst dapat dijamin keamanannya.

Implikasi: Penerapan IT security sesuai dengan standar policy dan

compliance yang ada.

4. Service Orientation

Pernyataan: Aplikasi bersifat modular dan di-desain sebagai

service/layanan dengan protokol open standard untuk

kemudahan interoperabilitas dan resource sharing.

Dasar pemikiran:Service orientation membuat aplikasi dibuat menjadi

modular dengan layanan/service yang dapat diakses tidak

hanya oleh aplikasi tersebut. Secara bisnis hal ini

bermanfaat dari segi reusability sehingga jika aplikasi lain

membutuhkan hal yang sama maka dapet menggunakan

kembali layanan yang sudah ada (terjadi resource sharing)

sehingga menjadi lebih efisien. Dengan terjadinya resource

sharing diharapkan tercapai economies of scale.

Implikasi: Penerapan arsitektur berorientasi layanan, penerapan

layanan dengan pola komunikasi yang bersifat open

standard

48


5. Penggunaan kembali

Pernyataan: Selalu mengedepankan penggunaan aplikasi dan

infrastruktur yang sudah ada. Jika tidak memungkinkan

maka dipilih pembelian aplikasi yang berupa standard

package yang memenuhi kebutuhan (COTS/commercial of

the shelf). Jika tidak memungkinkan maka dilakukan

custom development.

Dasar pemikiran: Dengan mengedepankan penggunaan aplikasi dan

infrastruktur yang sudah ada maka hal ini memberikan

keuntungan yang juga diharapkan oleh stakeholder (CTO),

yaitu dapat memenuhi permintaan klien dengan cepat.

Implikasi:

o Penggunaan kembali aplikasi dan infrastruktur yang

sudah ada untuk memenuhi permintaan klien

o Pembelian aplikasi atau kerjasama dengan pihak lain

untuk menggunakan aplikasi yang bersifat standard

package yang memenuhi kebutuhan/COTS.

6. Business Continuity

Pernyataan: Sistem dapat tetap berjalan walaupun terjadi gangguan.

Gangguan dapat berupa kegagalan hardware, kerusakan

data ataupun bencana alam.

Dasar pemikiran: Dalam industri airline ketersediaan sistem menjadi hal

utama. Ketersediaan sistem dituntut untuk selalu

beroperasi 24/7 terutama untuk aplikasi-aplikasi yang

bersifat operasional sehari-hari. Hal ini menjadi dasar

diperlukannya prinsip arsitektur business continuity agar

sistem dapat tetap berjalan walaupun terdapat gangguan

Implikasi:

o Aplikasi dan infrastruktur mempunyai tingkat

ketersediaan yang tinggi

o Aplikasi mendukung clustering/redundancy dengan

model aktif-aktif ataupun aktif-pasif

49


7. Identity management

Pernyataan: Identity management bersifat terpusat dan data user untuk

seluruh aplikasi bersifat terpusat.

Dasar pemikiran: Aplikasi pada industri airline jumlahnya semakin

berkembang seiring dengan meningkatnya kebutuhan

bisnis. Beberapa aplikasi digunakan oleh internal airline

dan beberapa lainnya digunakan oleh penumpang/calon

penumpang. Dengan semakin banyaknya aplikasi maka

peluang terjadinya duplikasi data akan menjadi semakin

besar dan dengan demikian akan memliki keterbatasan-

keterbatasan dan menjadi tidak efisien. Identity

management yang bersifat terpusat akan menyimpan data

user/pengguna sistem secara terpusat agar dapat digunakan

bersama. Hal ini mendorong adanya resource sharing.

Implikasi: Penerapan identity management secara terpusat

• Prinsip-prinsip data

8. Corporate data model

Pernyataan: Pendefinisian data model yang digunakan dalam aplikasi-

aplikasi yang ada untukdigunakan sebagai acuan data

model acuan.

Dasar pemikiran: Dalam proses bisnis sehari-hari banyak ditemukan data

yang pada esensinya sama tetapi strukturnya berbeda. Hal

ini membuat terdapat duplikasi data dan diperlukan

transformasi data jika dikirimkan ke aplikasi lain.

Corporate data model akan mendefinisikan data model

untuk digunakan dalam aplikasi-aplikasi sehingga akan

membuat pengembangan aplikasi menjadi lebih cepat

(faster time to market).

Implikasi:

o Penerapan corporate data model sebagai common data

model bagi aplikasi yang ada.

50


• Prinsip-prinsip aplikasi

9. Kemudahan penggunaan

Pernyataan: Aplikasi harus bersifat user-friendly dan mudah digunakan.

Aplikasi akan mempunya common look and feel.

Dasar pemikiran: Aplikasi yang mempunyai common look and feel yang

seragam akan memudahkan pengguna aplikasi. Lebih jauh

lagi dapat dibuat suatu template sebagai basis dari

pegembangan aplikasi yang bersifat reusable dan dapat

digunakan oleh berbagai aplikasi. Dengan demikian akan

didapat beberapa keuntungan tambahan seperti faster time

to market dan didapat resource sharing.

Implikasi:Pengembangan aplication foundation untuk aplikasi yang

sifatnya inhouse atau custom build.

• Prinsip-prinsip teknologi

10. Interoperability

Pernyataan: Bersifat open standard tidak bergantung pada spesifik

teknologi tertentu sehingga antar aplikasi dapat

berkomunikasi.

Dasar pemikiran:Dengan ditetapkannya salah satu requirement of

architecture work berupa penggunaan-penggunaan standar-

standar teknologi yang bersifat best practice standard maka

interoperability antar aplikasi menjadi bersifat open

standard. Secara bisnis hal ini akan memudahkan

konektivitas ke berbagai sistem lain baik sistem inhouse

yang dimiliki Asyst ataupun sistem milik pihak ketiga.

Dengan demikian time to market juga akan menjadi lebih

cepat.

Implikasi: Aplikasi yang dikembangkan mempunyai layanan yang

menggunakan teknologi berbasis open standard.

5.2 Kondisi Enterprise Saat Ini

Bagian ini akan menggambarkan kondisi enterprise saat ini. Hal ini meliputi

beberapa hal dimulai diagram value chain yang akan menggambarkan proses

51


bisnis yang ada, kemudian diikuti dengan pemetaan stakeholder. Selanjutnya

enterprise architecture saat ini akan dijelaskan melalui arsitektur bisnis, arsitektur

sistem informasi dan arsitektur teknologi. Bagian ini juga akan menjelaskan

permasalahan yang dihadapi oleh berbagai stakeholder. Dikarenakan research

question yang ingin dijawab dari penelitian ini adalah bagaimana enterprise

architecture yang dapat mengakomodir bisnis inti airline, maka gambaran yang

diambil adalah gambaran enterprise architecture dari sisi airline. Hal ini sejalan

dengan salah satu layanan Asyst yang difokuskan pada penelitian ini yaitu

airline, transportation and travel solutions (ATTS) sehingga nantinya EA yang

dihasilkan dapat menjawab research question dengan berfokus pada layanan

Asyst di bidang ATTS.

5.2.1 Diagram Value Chain

Diagram value chain menggambarkan proses inti dan juga proses pendukung yang

ada pada sebuah airline. Diagram value chain diilustrasikan pada gambar 5.1.

- Pricing- Network planning- Aircraft management- Crew management

Planning & Scheduling

- Check-in- Departure control- Flight operation- Catering management

Pre-Flight

- Reservation- Ticketing

Sales

- In flight service

In-Flight

- Baggage service- Flight connections- Customer loyalty/relationship management- Maintenance

Post-Flight

- Accounting, revenue managementSupport activitiesInfrastructure

- Personnel, recruitment, airline personnel training, agent trainingHuman-resource management

- PurchasingProcurement

Profit

Gambar 5.1 Diagram value chain airline

Pada gambar 5.1 value chain sebuah airline memiliki 5 proses inti dan beberapa

proses pendukung. Proses inti dari airline terdiri atas planning and scheduling,

sales, pre-flight, in-flight, dan post-flight. Berikut penjelasan lebih detail dari

proses-proses tersebut:

52


1. Planning and scheduling

Planning and scheduling adalah proses yang akan meliputi beberapa hal

diantaranya adalah penentuan harga (pricing), perencanaan rute penerbangan

(network planning), manajemen pesawat (aircraft management) dan

manajemen kru pesawat (crew management).

2. Sales

Sales adalah proses penjualan dimana jadwal penerbangan yang telah dibuat

pada proses sebelumnya dapat dijual ke calon penumpang. Bagian utama dari

proses penjualan ini adalah proses reservasi dan ticketing. Proses sales

sendiri dapat dilakukan melalui beberapa jalur distribusi (distribution

channel) bergantung pada kebijakan dari masing-masing airline. Beberapa

pola yang umum dari proses penjualan adalah melalui agen perjalanan dan

melalui internet booking engine, yaitu melalui website milik airline yang

mempunyai fasilitas melakukan reservasi.

3. Pre-flight

Pre-flight adalah hal-hal yang berkaitan dengan proses sebelum penerbangan

dan merupakan kelanjutan dari proses penjualan. Beberapa aktivitas yang ada

didalam pre-flight yaitu proses departure control, check-in, flight operation,

dan catering management.

4. In-flight

In-flight adalah proses-proses yang berkaitan dengan saat penerbangan. Hal

ini contohnya adalah layanan yang didapat oleh penumpang saat penerbangan

di dalam pesawat.

5. Post-flight

Post-flight adalah aktivitas yang berkaitan dengan proses setelah

penerbangan. Beberapa hal yang tercakup dalam post-flight antara lain adalah

baggage service, flight connections, customer loyalty/relationship

management, aircraft maintenance.

53


5.2.2 Pemetaan stakeholder

Dalam mengelola proses bisnis yang terkait dengan airline, terdapat beberapa

stakeholder yang teridentifikasi dan disajikan dalam daftar stakeholder. Tabel 5.1

menggambarkan stakeholder yang terkait dalam domain permasalahan. Daftar

stakeholder yang ada pada tabel 5.1 meliputi stakeholder yang ada di Asyst

sebagai penyedia solusi dan juga stakeholder yang ada pada airline sebagai

pengguna jasa solusi yang disediakan oleh Asyst.

Tabel 5.1 Daftar stakeholder

No Stakeholder Keterangan

Asyst

1 CTO Merencanakan, mengorganisasikan,

mengelola dan mengendalikan seluruh

kegiatan di direktorat teknik yang

meliputi Departemen Mainframe System,

Solutions Development, Application

Development dan Program Management

Office (PMO).

2 Account Management -

Airline

Memastikan perencanaan, koordinasi,

pengendalian, dan evaluasi seluruh fungsi

dan aktivitas penjualan serta pembinaan

hubungan baik dengan pelanggan pada

seluruh operasional Departemen Account

Management, telah dilaksanakan sesuai

dengan target bisnis perusahaan.

3 Product Management Memastikan perencanaan, koordinasi,

pengendalian, dan evaluasi seluruh desain

product management dilaksanakan sesuai

dengan ketentuan, kebijakan, rencana

strategis dan bisnis perusahaan.

Airline

4 Airline – Commercial and Bertanggungjawab menyediakan produk,

54


No Stakeholder Keterangan

Business melakukan market research, merancang

distributionchannel, promotion, market

share,flight master record (FMR)

management/rute pesawat,

mempublikasikan jadwal pada sistem,

flight inventory management, seat

allocation, waitlist management,

overbooking management, fare

management, manage open flight for

check-in, seat assignment, process

passenger boarding, penjualan.

5 Airline - Operation Bertanggungjawab agar pesawat terbang

on time, melakukan operasi penerbangan

(departure flight), crew management,

flight log, network planning, aircaft

management.

6 Airline - Maintenance Bertanggungjawab agar pesawat tidak

mengalami problem, mempersiapkan

pesawat (aircraft) agar siap digunakan,

maintenance, spare part.

7 Airline – Accounting and

Finance

Bertanggungjawab agar pendapatan dapat

diketahui dengan cepat, tepat dan akurat,

kemudian melakukan penghitungan

revenue berdasarkan tiket-tiket yang

diterbangkan (operation).

8 Agen Perjalanan Bertindak sebagai salah satu distribution

channel bagi airline untuk menjual

produknya.

55


5.2.3 Arsitektur Bisnis

Pada tahap ini akan dibahas tentang arsitektur bisnis yang ada pada sebuah airline.

Pada umumnya arsitektur bisnis yang ada pada tiap-tiap airline adalah serupa dan

tergambarkan dalam gambar 5.2.

Arsitektur bisnis pada gambar 5.2 menggambarkan proses-proses bisnis yang ada

pada sebuah airline. Arsitektur bisnis yang ada adalah selaras dengan value chain

dari airline yang telah disampaikan sebelumnya.

Proses bisnis diawali dengan adanya penentuan harga melalui suatu mekanisme

pricing. Penentuan harga akan menghasilkan besaran harga dari jadwal

penerbangan yang akan dijual ke calon penumpang. Besaran harga akan bersifat

detail untuk setiap sub-class yang ada ditambah dengan berbagai kombinasi lain

seperti harga untuk dewasa, anak-anak dan bayi, diskon pada periode tertentu,

diskon pada jadwal tertentu, dan lain-lain.

Pricing

Network Planning

Crew Management

Reservation

Ticketing

Check-in

Departure Control

Flight Operation

Catering Management

In-Flight Service Baggage Service

Revenue Management

Customer Loyalty/Relationship Management

Maintenace & Engineering Management

Proses Bisnis Inti

Proses Bisnis Pendukung

Flight Connections

Aircraft Management

Internal AuditCargo Management

Gambar 5.2 Arsitektur bisnis airline

Proses lain pada tahap awal adalah network planning, yaitu penyusunan jadwal

seasonal/per musim 2 kali setahun. Selain jadwal seasonal akan disusun juga

jadwal lebih detail untuk pengelolaan jadwal selama 60 hari kedepan. Perubahan

dapat terjadi dari jadwal seasonal misalnya jika terdapat kerusakan pada aircraft

56


ataupun misalnya karena cuaca buruk. Pengelolaan jadwal yang lebih dekat ke

jadwal keberangkatan juga dilakukan untuk 3 hari kedepan. Dengan demikian

secara umum terdapat pengelolaan jadwal seasonal, 60 hari kedepan, dan 3 hari

kedepan.

Selain dua proses di atas, proses lain yang juga menjadi bagian dari tahap awal

adalah aircraft management. Aircraft management akan mengatur jadwal

seasonal untuk aircraft. Aircraft management juga akan registrasi terhadap

pesawat baru yang belum terdaftar.

Proses lainnya pada tahap awal adalah crew management. Crew management

mengatur penugasan crew pesawat untuk setiap pairing route. Pairing route

dalam hal ini sebagai contoh adalah misalnya penerbangan dari Cengkareng ke

Yogyakarta kemudian kembali lagi dari Yogyakarta ke Cengkareng. Jika ditulis

kembali dengan pola three letter code, maka pairing route-nya akan menjadi

CGK-JOG-CGK. Crew managament akan melakukan penugasan/assignment

crew untuk pairing route tersebut. Selain itu crew managament juga melakukan

fungsi tracking dan monitoring terhadap crew. Hal lain yang dilakukan oleh crew

management adalah melakukan penjadwalan untuk stand-by crew. Stand-by crew

diperlukan jika crew yang ditugaskan ternyata berhalangan.

Selanjutnya dari planning dan scheduling yang telah dilakukan akan dilanjutkan

dengan proses reservasi. Proses reservasi adalah proses untuk melakukan

booking/pembukuan terhadap flight schedule yang ada. Jika pembukuan telah

selesai dilakukan maka dapat dilanjutkan dengan proses ticketing. Proses

ticketing akan melibatkan proses pembayaran dimana calon penumpang akan

membayarkan sesuai dengan pricing yang sebelumnya telah dibuat.

Proses selanjutnya setelah ticketing adalah proses pre-flight, yaitu aktivitas-

aktivitas yang terkait dengen persiapan keberangkatan pesawat. Hal ini meliputi

proses departure control dan check-in. Aktivitas lainnya yang ada pada tahap ini

adalah catering management yang akan menyiapkan makanan saat di pesawat

nantinya. Aktivitas flight operation yang berhubungan dengan persiapan teknis

keberangkatan pesawat juga dilakukan pada tahap ini. Aktivitas flight operation

57


meliputi aktivitas-aktivitas yang akan menghasilkan rute penerbangan yaitu rute

yang akan dilewati pesawat dari satu station ke station yang lain.

Pada saat di pesawat proses yang ada adalah berupa in-flight service bagi

penumpang. Hal ini meliputi penyediaan makanan, atau hal-hal lain jika

penumpang memiliki permintaan khusus misalnya vegetarian meal atau hal

khusus lainnya.

Proses akhir tercakup dalam post-flight, yaitu aktivitas setelah penerbangan. Hal

ini meliputi layanan bagasi, koneksi ke penerbangan lain jika ada dan lain-lain.

Salah satu hal yang juga menjadi layanan dari airline adalah customer

loyalty/relationship management. Contoh dari hal ini adalah frequent flyer

program (FFP). Dalam FFP¸ penumpang akan memperoleh poin tertentu setelah

melakukan penerbangan. Dari poin-poin yang ada nantinya penumpang akan

memperoleh manfaat-manfaat tertentu seperti misalnya dapat melakukan

pembelian tiket dengan menggunakan poin yang dimiliki.

Selain proses-proses yang ada pada proses bisnis inti terdapat juga proses bisnis

pendukung seperti pada kargo, revenue management dan internal audit. Proses

bisnis pendukung tidak akan dibahas dalam penelitian ini karena berada di luar

batasan penelitian. Satu proses yang terdapat dalam proses bisnis inti juga tidak

akan dibahas, yaitu proses bisnis yang terkait dengan maintenance and

engineering management. Hal ini dikarenakan beberapa hal yaitu: 1) bukan

termasuk bisnis proses yang didukung oleh Asyst; 2) kompleksitas pada bisnis

proses ini batasannya luas dan kompleks sehingga diperlukan enterprise

architecture tersendiri.

5.2.4 Arsitektur Sistem Informasi

Arsitektur sistem informasi terdiri dari arsitektur data dan arsitektur aplikasi.

Arsitektur data dan arsitektur aplikasi akan menggambarkan bagaimana arsitektur

bisnis dapat dijalankan. Berikut akan dijelaskan arsitektur data dan arsitektur

aplikasi yang dapat diidentifikasi pada kondisi saat ini.

58


5.2.4.1 Arsitektur Data

Pada bagian ini dijelaskan tentang arsitektur data pada kondisi saat ini. Arsitektur

data diilustrasikan pada gambar 5.3. Arsitektur data berkaitan dengan erat dengan

aplikasi yang ada dikarenakan data disimpan atau dihasilkan oleh aplikasi-aplikasi

yang ada. Pada akhirnya data dan aplikasi tersebut akan membentuk suatu sistem

yang mendukung proses-proses bisnis.

59


Revenue Management System

Network Planning & Schedulling System

Aircraft Management System

Crew Management System

PSS

IBE-B2TIBE-B2C

FIDS Meal Monitoring

CFDFOQA E-Briefing AIRCOMSentinel

Ops Control

Cargo Solution

FFP

Revenue Accounting Systen

Sales Dashboard

SSIM

ASM/SSM

Crew Data and Schedule

APIS Crew

Blackbox Data Fligt Log ACARS Data

Fligt Availability and Fare

PassengerBooking and Ticketing

Data

FlightInformation

Checked-InPassenger

Ticket Sales and Flown

Passenger Flown Data

Fare Data

Flight Plan

PNR and Ticket

APIS Pax

Baggage Data

Flight Connection Data

Customer FIle

Gambar 5.3 Arsitektur data Pada tabel 5.2 disajikan keterangan tentang data yang terdapat pada arsitektur data

dalam gambar 5.3.

60


Tabel 5.2 Keterangan data

No Data Keterangan

1. Fare data Fare data adalah data yang berisikan

informasi harga dari flight schedule yang ada.

Informasi fare dibuat berdasarkan fare rules

yang ada dan dapat mempunyai banyak

kombinasi. Kombinasi-kombinasi ini

contohnya adalah perbedaan harga untuk

setiap subclass, tipe penumpang (dewasa,

anak-anak, bayi), diskon tertentu untuk tipe

penumpang/nomor penerbangan/rute tertentu,

penerbangan direct atau transit,

refundable/non refundable dan lain-lain.

Data ini dihasilkan oleh aplikasi revenue

management system dan akan diinput

kedalam PSS.

2. Flight plan Flight plan adalah data perencanaan

penerbangan. Data ini meliputi bahan bakar,

kondisi cuaca, rute penerbangan, termasuk

juga data PIC (pilot in charge).

3. SSIM SSIM adalah singkatan dari standar schedule

information message. SSIM adalah data yang

merupakan standar dari IATA dan berisikan

informasi jadwal penerbangan. Pada

arsitektur data dalam gambar 5.3, SSIM

dibuat seasonal dua kali dalam setahun.

4. ASM/SSM ASM/SSM adalah schedule message/standard

schedule message. ASM/SSM berisikan

perubahan jadwal yang mencakup perubahan

aircraft, rute, dan waktu penerbangan.

5. Crew data dan

schedule

Crew data dan schedule adalah data yang

berisikan informasi crew yang bertugas untuk

61


No Data Keterangan

suatu flight schedule.

6. APIS crew API (advance pax info) atau sering juga

disebut sebagai APIS (advance passenger

information system) adalah data yang

digunakan untuk keperluan imigrasi. Dalam

hal ini terdapat dua jenis APIS yaitu APIS

crew untuk crew pesawat dan dan APIS pax

untuk penumpang yang terbang dalam flight

schedule.

7. Blackbox data Blackbox data merupakan data yang

tersimpan dalam blackbox suatu pesawat.

Data ini nantinya dapat disimulasikan untuk

mengetahui hal-hal yang terjadi di pesawat

dari mulai tinggal landas sampai dengan

mendarat

8. Fligt log Data yang berisi catatan kejadian-kejadian

penerbangan diluar prediksimisal pintu

darurat tak terbuka, safety belt macet, satu

mesin mati dan lain-lain.

9. Flight availability

and fare

Flight availability adalah data tentang

ketersediaan seat dari suatu flight schedule.

Setiap data flight availability adalah untuk

suatu pasangan origin dan destination

tertentu. Flight availability akan

menampilkan seluruh nomor penerbangan

yang tersedia dengan rincian subclass-nya.

Sedangkan data fare adalah rincian harga

untuk setiap informasi flight availability yang

ada.

10. Passenger booking

and ticketing data

Passenger booking and ticketing data adalah

data yang dikirimkan jika melakukan booking

62


No Data Keterangan

dan ticketing. Data ini merupakan lanjutan

dari proses booking dan ticketing setelah

sebelumnya diterima data flight availability

and fare

11. PNR (passenger

name record) dan

tiket

PNR adalah data yang dihasilkan jika proses

booking berhasil dilakukan. PNR akan berisi

nama penumpang yang telah melakukan

booking untuk suatu flight schedule tertentu,

flight schedule yang diinginkan dan

informasi-informasi pelengkap lain seperti

data kontak penumpang.

Sedangkan tiket adalah data yang dihasilkan

jika proses ticketing berhasil dilakukan.

Serupa dengan PNR, tiket juga berisikan data

penumpang dan fligt schedule yang

diinginkan. Hanya saja untuk tiket

perbedaannya adalah juga memuat informasi

harga berikut rinciannya dan termasuk juga

metode pembayaran yang dilakukan untuk

melakukan ticketing.

12. Passenger flown

data

Passenger flown data berisikan data

penumpang yang telah melakukan

penerbangan. Data ini dihasilkan dari sistem

reservasi di PSS dan digunakan oleh aplikasi

customer loyalty system sebagai pencatatan

mileage yang nantinya akan dikonversi

menjadi poin dalam aplikasi customer loyalty

system.

13. Customer file Customer file berisikan data customer, yaitu

mereka yang pernah terbang bersama dengan

airline dan terdaftar sebagai anggota FFP.

63


No Data Keterangan

14. Flight information Flight information berisikan data real time

status suatu jadwal penerbangan. Melalui

data ini, dapat dipantau status terakhir dari

suatu jadwal penerbangan.

15. Checked-in

passenger

Data checked-in passenger adalah data yang

berisikan penumpang yang telah melakukan

check-in untuk suatu jadwal penerbangan

tertentu. Data ini didapatkan dari sistem DCS

pada PSS.

16. APIS pax APIS pax adalah data yang serupa dengan

APIS crew, hanya saja APIS pax memuat data

penumpang dari suatu jadwal penerbangan

tertentu

17. Baggage data Baggage data adalah data bagasi penumpang.

Data ini terdapat pada sistem DCS pada PSS

18. Flight connection

data

Suatu airline dapat menjalin kerjasama

dengan masing-masing airline dapat

memperoleh dan melakukan reservasi airline

partner-nya. Data flight connection memuat

informasi penerbangan penghubung untuk

penumpang.

19. Ticket sales and

flown

Ticket sales adalah data yang memuat

informasi penjualan tiket dari suatu airline.

Data ini digunakan untuk kebutuhan akunting.

Sedangkan ticket flown adalah data yang

memuat informasi tentang tiket yang sudah

digunakan untuk terbang. Data ini juga

dibutuhkan untuk kebutuhan akunting.

20. ACARS data Data ACARS (Aircraft Communications

Addressing and Reporting System), yaitu data

komunikasi antara pesawat dan station.

64


5.2.4.2 Arsitektur Aplikasi

Bagian berikut berisi tentang pembahasan arsitektur aplikasi yang ada saat ini di

Asyst untuk melayani airline. Arsitektur aplikasi tersebut disajikan dalam gambar

5.4.

Aplikasi yang terdapat dalam gambar 5.4 berfungsi untuk mendukung proses

bisnis pada sebuah airline. Pada beberapa proses bisnis terdapat lebih dari satu

aplikasi yang digunakan. Untuk lebih jelasnya, fungsi dari masing-masing

aplikasi dijelaskan dalam tabel 5.3.


Pricing

Network Planning

Crew Management

Reservation

Ticketing

Check-in

Departure Control

Flight Operation

Catering Management


Revenue Management




E-Briefing

PSS

PSS

PSS

PSS

PSSIBE-B2C

IBE-B2T


FFP

Meal Monitoring

IBE-B2C

IBE-B2T

Revenue Accounting System

PSS


Flight Connections

PSS

Proses Bisnis Inti

Aircraft management


Internal Audit

AIRCOM

Ops Control Sentinel

FOQA

Sales Dashboard

FIDS

CFD

Cargo Management

Cargo solutions

Gambar 5.4 Arsitektur sistem informasi saat ini

Tabel 5.3 Portofolio Aplikasi

No Keterangan

1. Revenue management system

Fungsionalitas:

Revenue management system (RMS) digunakan untuk membuat

skema pricing dari jadwal penerbangan yang ada. Dengan RMS

maka harga yang dibuat dimaksimalkan untuk memperoleh

65


No Keterangan

pendapatan yang paling optimal.

Unit terkait:Airline – Commercial and Business

2. Network Planning and Scheduling System

Fungsionalitas:

Membuat jadwal penerbangan seasonal/per musim dalam setahun

sebanyak 2 kali. Jadwal juga akan dikelola lebih detail untuk 60

hari kedepan dan 3 hari kedepan. Pengelolaan jadwal dengan

periode lebih kecil (60 dan 3 hari kedepan) dimaksudkan jika ada

perubahan yang sifatnya ad-hoc. Hal ini dapat terjadi misalnya

karena ada kerusakan pada aircraft atau karena cuaca buruk

Unit terkait: Airline - Operation

3. Aircraft Management System

Fungsionalitas:

Sistem yang mengatur jadwal seasonal untuk aircraft, registrasi

terhadap aircraft baru dan juga mengatur perubahan-perubahan dari

jadwal yang sudah dibuat. Jika terjadi perubahan maka sistem akan

mengeluarkan message yang berisi kondisi perubahan. Perubahan-

perubahan yang dapat dilakukan meliputi perubahan aircraft, rute

dan waktu.


4. Crew Management System

Fungsionalitas:

Sistem yang mengatur penjadwalan dan penugasan crew untuk

setiap pairing route. Melakukan tracking dan monitoring terhadap

crew. Melakukan penjadwalan stand-by crew jika nantinya crew

yang ditugaskan berhalangan. Sistem juga melakukan pengecekan

secara periodik untuk melihat perubahan aircraft agar penjadwalan

crew selalu tersinkronisasi dengan penjadwalan aircraft.


5. PSS

Fungsionalitas:

66


No Keterangan

Merupakan sistem informasi yang paling utama dari sebuah airline

dan menangani hal-hal sebagai berikut:

• Reservasi penumpang

1. Inventory dan revenue management

Dapat terintegrasi dengan sistem RMS dan menangani

manajemen inventoryuntuk menentukan sub-class mana

saja yang tersedia dengan jumlah seat tertentu.

2. Codeshare

Merupakan kerjasama antar airline dengan bentuk misal

airline A menjual jadwal penerbangan airline B. Dalam

hal ini airline A disebut dengan codeshare marketing dan

airline B disebut dengan codeshare operating.

3. Fungsi GDS (global distribution system)

Merupakan salah satu bentuk distribution channel untuk

penjualan. Dalam hal ini GDS melakukan request jadwal

penerbangan airline berikut fare-nya. Dengan demikian

booking dapat dilakukan melalui GDS melalui model

komunikasi spesifik yang sesuai dengan standar protokol

airline.

4. Prosedur pembukuan/booking jadwal penerbangan

Prosedur untuk melakukan booking terhadap suatu jadwal

penerbangan tertentu. Informasi booking akan disimpan di

PSS dalam suatu record yang dinamakan PNR (passenger

name record)

5. Scheduling

Manajemen jadwal penerbangan. PSS dapat melakukan

action tertentu jika misalnya terdapat perubahan jadwal

penerbangan

6. Availability

Manajemen ketersediaan jadwal penerbangan. Informasi

yang ditampilkan adalah ketersedian suatu jadwal

67


No Keterangan

penerbangan untuk setiap city pair (pasangan tempat asal

dan tujuan). Informasi akan berupa seluruh nomor

penerbangan yang ada berikut dengan subclass yang

tersedia.

7. Fare quotation dan ticketing (FQT)

FQT memuat informasi yang berkaitan dengan fare (harga)

dari suatu jadwal penerbangan. FQT dapat mempunyai

aturan-aturan khusus (fare rules) sehingga dapat bersifat

dinamis. Aturan-aturan ini antara lain harga khusus untuk

dewasa, anak-anak dan bayi, harga khusus untuk jadwal

penerbangan tertentu atau diskon tertentu, perbedaan harga

untuk penerbangan transit dan direct, dan lain-lain. Data

pada FQT disimpan pada PSS berupa data tiket (ticket

image) dan nantinya akan difinalisasi bergantung pada

kondisi akhir (flown, void, exchange)

8. Queue handling

Queue handling adalah modul internal PSS untuk

keperluan bisnis tertentu. Pada PSS terdapat queue atau

suatu tempat yang menyimpan referensi ke PNR atau

message. Seperti terdeskripsi dari namanya, queue bersifat

first in first out (FIFO) dengan data PNR/message yang

ada di awal akan keluar dari queue terlebih dahulu.

Penggunaan queue secara bisnis dilakukan dengan

mengalokasikan queue tertentu untuk keperluan bisnis

tertentu. Misalnya dialokasikan bahwa queue nomor 3

adalah untuk PNR yang mengalami perubahan jadwal,

kemudian queue nomor 48 adalah untuk PNR yang

membawa bayi sehingga perlu penanganan khusus.

• Departure control system (DCS)

1. Check-in

Modul check-in akan menangani keseluruhan proses

68


No Keterangan

check-in penumpang. Hal ini meliputi proses untuk men-

generate boarding pass, penanganan bagasi termasuk juga

pemilihan seat.

2. Load control

Load control akan memastikan bahwa muatan pesawat

sesuai dengan standar dengan kondisi yang seimbang

(weight and balance yang sesuai)

3. API (advance pax info)

DCS juga memiliki modul API atau sering juga disebut

sebagai APIS (advance passenger information system)

yang akan men-generate suatu message dengan format

tertentu untuk keperluan imigrasi. API diperlukan

bergantung pada negara tujuan penerbangan.

4. APP (advance pax procedure)

DCS juga memiliki modul APP yang cara kerja dan

fungsinya memiliki kemiripan dengan APIS. Message

APP juga akan dikirimkan ke negara tujuan penerbangan

untuk keperluan bea cukai

5. Flight info

Flight info adalah modul yang dapat menampilkan

informasi jadwal penerbangan ke penumpang termasuk

juga status dari penerbangan tersebut.

• Message switching

Message switching adalah modul di PSS yang menangani

komunikasi PSS dengan pihak eksternal. Hal ini terutama

dalam hubungannya dengan sistem PSS lain (host-to-host).

Message switching dapat mengirim dan menerima message dari

dan ke PSS melalui pola komunikasi sesuai dengan protokol

standar airline. Saat ini model komunikasi yang umum di

airline adalah dengan menggunakan protokol MATIP

(mapping of airline traffic over internet protocol).

69


No Keterangan

Unit terkait:

• Airline – Commercial and Business

• Airline - Operation

6. IBE-B2C

Fungsionalitas:

B2C adalah sistem informasi berbasis web yang dapat diakses

melalui internet dan memungkinkan calon penumpang untuk

melakukan booking dan ticketing secara mandiri. B2C juga

mempunyai kemampuan untuk proses pembayaran melalui payment

gateway. Saat ini B2C yang dimiliki oleh Asyst sudah mendukung

pembayaran melalui kartu kredit dan ATM. Untuk melakukan

proses booking dan ticketing, B2C berkomunikasi dengan PSS

melalui suatu middleware. Hal ini dikarenakan PSS belum

mendukung high level communication dan masih harus

berkomunikasi melalui low level protocol seperti MATIP.

Middleware yang ada akan menyediakan high level communication

layer dengan dukungan web service sehingga B2C berkomunikasi

dengan middleware melalui web service.

• Unit terkait:Airline – Commercial and Business

7. IBE-B2T

Fungsionalitas:

B2T adalah salah satu aplikasi yang berfungsi sebagai distribution

channel yang mengakomodasi kebutuhan agen perjalanan (travel

agent). Dengan adanya B2T, agen perjalanan dapat menangani

proses booking dan ticketing secara mandiri. Serupa dengan B2C,

B2T juga adalah aplikasi berbasis web yang dapat diakses melalui

internet. Dikarenakan dikhususkan untuk agen perjalanan, terdapat

beberapa perbedaan dengan B2C. Pada B2T seluruh informasi fare

dan availability akan ditampilkan dimana pada B2C hanya

ditampilkan fare termurah saja. Perbedaan lain adalah pada proses

ticketing. Pada B2T agen akan mempunyai sejumlah deposit

70


No Keterangan

sebelum melakukan ticketing. Jika suatu agen melakukan ticketing

maka saldo deposit untuk agen tersebut akan berkurang. Selain itu

B2T juga mempunyai sistem komisi. Dengan sistem komisi dari

setiap tiket yang di-issue oleh agen, maka akan ada jumlah komisi

tertentu untuk agen tersebut.


8. Meal Monitoring

Fungsionalitas:

Meal monitoring adalah sebuah sistem informasi yang mencatat

kebutuhan makanan/meal pada suatu jadwal penerbangan. Aplikasi

ini terkoneksi dengan DCS pada PSS. Data dari DCS dibutuhkan

karena meal monitoring mencatat jumlah penumpang yang akan

terbang.


9. Ops Control

Fungsionalitas:Ops control adalah sistem yang melakukan flight

planning dan operation control. Sistem ini mengambil data rotasi

pesawat dari aircraft management system dan kemudian diolah

menjadi sebuah flight plan. Flight plan juga memperhitungkan

jumlah bahan bakar dan juga keadaan cuaca.

Unit terkait:Airline - Operation

10. FOQA (flight operation and quality assurance)

Fungsionalitas:

Digunakan untuk membaca blackbox. Jika pesawat mendarat maka

data blackboxakan diekstrak. FOQA akan men-decrypt data di

blackbox untuk dibaca. Dari data yang ada dapat dibuat simulasi

dari take off sampai landing. FOQA bisa membaca tergantung data

pesawat yang ada. FOQA digunakan untuk internal audit.


11. E-Briefing

Fungsionalitas:aplikasi yang berisikan prosedur, keamanan, aturan

71


No Keterangan

penampilan untuk crew. Aplikasi ini terkoneksi ke database crew

management system.

Unit terkait:Airline - Operation

12. AIRCOM (air ground communication)

Fungsionalitas:AIRCOM menangani komunikasi pesawat dan

station


13. Sentinel

Fungsionalitas: Sentinel berfungsi untuk mencatat kejadian-kejadian

penerbangan diluar prediksi, misalnya pintu darurat tak terbuka,

safety belt macet, terdapat mesin mati dan lain-lain. Sentinel

mengeluarkan laporan dan nantinya akan diputuskan action

selanjutnya supaya hal tersebut tidak terjadi lagi. Keputusan akan

dilakukan oleh personel berdasarkandata yang ada pada Sentinel.

Sentinel lebih berfungsi untuk risk management dengan user

aplikasi adalah dariinternal audit dan dioperasikan oleh flight

operation.


14. FFP (sMile)

Fungsionalitas:sMile adalah sebuah frequent flyer program.

Dengan sMile penumpang dari airline yang terdaftar sebagai

anggota frequent flyer program mempunyai kesempatan untuk

mengakumulasi miles pada saat bepergian dengan jasa airline.

Nantinya miles yang terkumpul dapat ditukarkan dengan tiket,

mendapat upgrade dari ekonomi ke kelas bisnis atapun award lain

seperti promosi spesial tertentu.

Unit terkait: Airline – Commercial and Business

15. CFD (centralized flight dispatch)

Fungsionalitas:

Solusi untuk manajemen paket perjalanan antara flight dispatcher

dan pilot in command (PIC) secara real-time.

72


No Keterangan


16. FIDS (flight information display system)

Fungsionalitas:

Disebut juga dengan flight monitoring, adalah sebuah solusi untuk

memonitor keberangkatan dan kedatangan untuk industri airline.


5.2.5 Arsitektur Teknologi Saat ini

Pada tahap ini dijelaskan arsitektur teknologi secara umum dari sistem yang ada.

Arsitektur teknologi sebagai baseline hanya akan membahas dari sisi topologi

infrastruktur yang digunakan. Pada iterasi kedua dari ADM akan dibahas lebih

detail dari arsitektur teknologi dilengkapi dengan penerapan-penerapan dari

prinsip-prinsip arsitektur yang digunakan. Hal ini juga merujuk ke solusi dari

permasalahan-permasalahan yang diidentifikasi sehingga arsitektur teknologi pada

iterasi kedua dari ADM diharapkan dapat mengakomodasi permasalahan-

permasalahan tersebut.

Topologi infrastruktur diilustrasikan pada gambar 5.5. Saat ini Asyst memiliki 2

buah data center dengan salah satunya bertindak sebagai DRC. Kedua data

center tersebut terhubung ke jaringan internet dan juga terhubung ke jaringan

SITA. Konektivitas ke jaringan SITA dibutuhkan karena beberapa pengiriman

data misalnya pengiriman telex antar station saat ini masih menggunakan jaringan

SITA.

Spesifik untuk aplikasi PSS Compass, digunakan mainframe dengan tipe IBM

Z10. Untuk aplikasi lain sudah menggunakan teknologi virtualization

menggunakan Vmware dengan media penyimpanan menggunakan SAN (storage

area network).

73


Hosting Place/Virtual Machines

Storage

High EndRouter

SITA

MPLS Telkom

Other TrustedNetwork

Internet

Public User

Public User

Mainframe


Storage

High EndRouter

DATA CENTER

DRC

Firewall

Load Balancer

Core Switch

Access Switch

Distribution Switch

Server Switch

Distribution Switch

Distribution Switch

Medium Switch

Switch

MediumRouter

Firewall

Mainframe

Core Switch

Distribution Switch

Distribution Switch

Load Balancer

Server Switch

Access Switch

MediumRouter

Gambar 5.5 Topologi infrastruktur

5.2.6 Permasalahan Yang Dihadapi

Dari pemetaan stakeholder yang telah dilakukan maka dilakukan pemetaan

permasalahan yang dihadapi dari masing-masing stakeholder. Permasalahan yang

dihadapi ini dianalisis lebih lanjut untuk mendapatkan solusi yang sesuai.

Permasalahan-permasalahan yang dihadapi untuk masing-masing stakeholder

dijabarkan dalam tabel 5.4 berikut ini:

74


Tabel 5.4 Permasalahan yang dihadapi

No Permasalahan Keterangan

Stakeholder: CTO

1 Akses ke PSS masih

kurang efisien dan costly

Akses PSS dengan “black screen” atau

menggunakan console bersifat costly dan

kurang efisien. Contohnya adalah diperlukan

training berkelanjutan jika turnover pegawai

cukup tinggi. Hal ini juga dikarenakan sifat

dari akses menggunakan console dimana

pengguna diharuskan menghafal banyak

perintah sehingga memerlukan waktu yang

lama agar dapat menggunakan sistem dengan

baik.

2 Fungsi monitoring belum

memadai

Fungsi monitoring yang belum memadai

menyulitkan dalam menangani masalah

maupun melakukan perbaikan.

3 Belum ada dan

dibutuhkan PSS GUI

Diperlukan PSS GUI untuk menghasilkan

nilai jual yang lebih baik bagi PSS

4 Belum ada dan

dibutuhkan resource

sharing pada

infrastruktur

Dibutuhkan resource sharing pada

infrastruktur untuk mencapai economies of

scale

5 Belum ada dan

dibutuhkanresource

sharing pada aplikasi

Dibutuhkan resource sharing pada aplikasi

untuk mencapai economies of scale

6 Interkoneksi aplikasi

bersifat point-to-point

Arsitektur point-to-point kurang memberikan

fleksibilitas dikarenakan jika terjadi

perubahan pada suatu aplikasi maka aplikasi

lainnya yang terkait akan membutuhkan

perubahan. Hal ini mempengaruhi beberapa

sisi yaitu time-to-market, cost impact, dan

juga reliabilitas dan kinerja dari sistem

75



7 Interkoneksi dan layanan

antar aplikasi hanya

memperhatikan aplikasi

tersebut

Permasalahan yang ada pada poin ini adalah

sifat interkoneksi yang spesifik untuk aplikasi

tertentu sehingga jika ada aplikasi lain yang

membutuhkan interkoneksi dan layanan baru

maka harus dibuatkan service baru. Dalam

hal ini aspek reuseability belum sepenuhnya

dioptimalkan.

8 Belum ada sistem data

warehouse dan sistem

business intelligence

Hal ini adalah rencana dari CTO untuk

mengakomodir kebutuhan bisnis yang ada.

9 Belum ada customer

relationship management

system

Hal ini juga merupakan rencana dari CTO

untuk mengakomodir kebutuhan bisnis yang

ada.

Stakeholder: Account Management

10 Belum ada dan

dibutuhkan mobile access

untuk IBE dan check-in

Mobile access berupa mobile web dan native

client dengan dukungan fungsi yang

komprehensif meliputi reservasi dan check-in

11 Check-in hanya dapat

dilakukan melalui check-

in counter atau

perwakilan airline di kota

keberangkatan

Check-in yang lebih fleksibel yang dapat

dilakukan tidak hanya di check-in counter

pada airport dan kantor perwakilan airline di

kota keberangkatan

12 Belum ada dan

dibutuhkan fungsi pay for

purchase item saat

penumpang melakukan

booking

Fungsi pembelian yang dapat dilakukan pada

saat pre-flight untuk hal-hal yang bersifat in-

flight misalnya pembelian makanan dan hal-

hal lainnya.

13 Permintaan klien pada

B2T deposit management

yang tidak sesuai best

practice pada industri

Fungsi deposit management pada B2T yang

belum bersifat fleksibel dan kadang tidak

sesuai dengan keinginan dari klien.

76



Stakeholder: Airline – Commercial and Business

14 Belum ada dan

dibutuhkan API untuk

kerjasama dengan third

party seperti online travel

agent (OTA)

Kebutuhan akan adanya API ke sistem PSS

untuk memproses reservasi dan ticketing dari

OTA

15 Data kosong/fungsi

ticketing IBE kadang

mengalami masalah pada

pembayaran kartu kredit

Adanya data kosong, yaitu transaksi yang

sudah confirm dari sisi kartu kredit namun

tiket untuk penumpang tidak ter-create.

16 Data manifest tidak

terkirim

Tidak terkirimnya data manifest ke airline

dari sistem

17 Terjadi data discrepancy

antara data Compass

(PSS) dengan B2T

Data discrepancy yaitu terdapat perbedaan

data antara B2T dan PSS, contohnya

perbedaan data ticketing dengan di PSS sudah

ticketing namun pada B2T belum ticketing

18 Kesulitan menentukan

patokan harga sesuai

dengan segmen pasar

Tidak adanya yield management system,

sehingga departemen sales, marketing

kesulitan menentukan patokan harga sesuai

dengan segmen pasar

19 Tidak tersedianya data

statistik pejualan

Tidak tersedianya data statistik pejualanyang

dapat dianalisis guna melakukan

pengembangan pasar

Stakeholder: Airline - Agen Perjalanan

20 Kadang tidak bisa

melakukan payment

Payment tidak bisa dilakukan karena proses

ticketing yang gagal

21 B2T dan B2C kadang

tidak dapat search

availability

B2T dan B2C tidak menampilkan hasil sesuai

harapan pada saat pencarian jadwal

penerbangan

22 Komisi kadang tidak

masuk

Pada B2T, untuk setiap tiket yang dikeluarkan

oleh suatu agen, maka akan ada komisi untuk

77



agen tersebut. Pada beberapa kesempatan,

komisi tersebut tidak ter-update untuk agen

walaupun agen tersebut telah melakukan

proses ticketing

23 Booking tidak

mendapatkan ticketing

time limit

Kesalahan konfigurasi PCC (pseudo city

code) pada PSS atau PCC belum create

sehingga beberapa fungsi tidak berjalan

dengan semestinya

24 B2T system tidak bisa

diakses

Pada beberapa kesempatan B2T tidak bisa

diakses dan menimbulkan dampak operasional

langsung terhadap airline dikarenakan

penjualan yang terhambat

25 Koneksi jaringan di

daerah yang kurang baik

sehingga menghambat

sistem

Koneksi jaringan yang kurang baik terutama

di daerah menghambat agen untuk mengakses

sistem dan melakukan fungsi bisnis seperti

penjualan

26 Sales distributon harus

terhubung ke banyak

channel dan payment

Channel dan metode payment yang terbatas

memberikan hanya sedikit pilihan reservasi

dan pembayaran bagi calon penumpang dan

menjadikan sistem tidak fleksibel

Stakeholder: Airline - Operation

27 Optimizer untuk crew

management

Aplikasi untuk crew management yaitu

Netline crew memiliki optimizer

(penjadwalancrew otomatis, pairing dan

assignment) hanya saja optimizeryang ada

saat ini tidak berjalan karena adanya

perbedaan bisnis proses dengan user, tidak

semua crew ter-assign dan ada rule yang tidak

terakomodasi.

28 Rotation optimizer untuk

aircraft management

Rotation optimizer bertujuan untuk optimasi

agaraircraft agar selalu ter-utilize. Misalkan

78



pesawat mendarat, maka tidak terlalu lama

berada di ground karena tidak menghasilkan

revenue jika terlalu lama idle. Saat ini sudah

ada optimizer tetapi tidak sesuai

29 Komunikasi aplikasi di

flight ops memerlukan

suatu gateway yang

terkadang komunikasinya

tidak stabil

Beberapa aplikasi di flight operation

memerlukan pengiriman data melalui telex.

Saat ini pengiriman telex difasilitasi oleh

gateway yang dinamakan emedia. Terkadang

komunikasi melalui emedia tidak stabil.

30 Tidak bisa mencetak

flight plan

Hal ini terjadi karena load network yang

tinggi sehingga hasilnya pencetakanberupa

print telex tidak bisa dilakukan.

5.3 Perencanaan Enterprise Architecture

Setelah didefinisikan requirement of architecture work, kondisi baseline dan

permasalahan-permasalahan yang ada, maka selanjutnya adalah perencanaan

enterprise architecture yang dapat menjawab hal-hal di atas.

5.3.1 Solusi Permasalahan

Dari permasalahan-permasalahan yang ada diperlukan suatu solusi untuk

mengatasinya. Permasalahan yang telah diidentifiksi bersifat beragam dan karena

itu memerlukan solusi yang spesifik untuk setiap tipe permasalahan. Walaupun

demikian terdapat kemungkinan suatu solusi dapat diterapkan untuk memecahkan

beberapa permasalahan.

Merujuk ke permasalahan yang ada, ditetapkan suatu sasaran solusi yang jika

dicapai akan memecahkan permasalahan yang ada. Setelah didapat sasaran solusi

kemudian dilanjutkan dengan identifikasi pola solusi untuk kemudian dapat

diterapkan dalam suatu solusi SI/TI. Solusi-solusi dari permasalahan yang ada

disajikan dalam tabel 5.5.

79


Tabel 5.5 Pola solusi permasalahan

N

o

Permasalahan Sasaran Solusi Pola Solusi Solusi SI/TI

1 Akses ke PSS

masih kurang

efisien dan

costly

Akses ke PSS

yang efisien

• Efisiensi model

koneksi,

menghilangkan

layer yang tidak

efisien

• Penerapan SOA

• PSS service

• ESB

2 Fungsi

monitoring

belum memadai

Fungsi

monitoring yang

memadai

dengan

notifikasi jika

terjadi

irregularities

Implementasi

sistem monitoring

untuk aplikasi dan

infrastruktur

• Sistem

monitoring

Aplikasi

• Sistem

monitoring

infrastruktu

r

3 Belum ada dan

dibutuhkan PSS

GUI

Terdapat GUI

untuk

mengakses PSS.

Pengembangan

GUI untuk PSS

berbasis web

sehingga bersifat

thin client

• PSS GUI

• ESB

• PSS service

4 Belum ada dan

dibutuhkan

resource

sharing pada

infrastruktur

Resource

sharing

dilakukan untuk

mencapai

economies of

scale

Desain

infrastruktur

berbasis SOA

• Infrastruktu

r server dan

storage

• Infrastruktu

r jaringan

5 Belum ada dan

dibutuhkan

resource

sharing pada

Resource

sharing

dilakukan untuk

mencapai

Desain aplikasi

berbasis SOA

dengan pengunaan

layanan bersama

ESB

80


N

o


aplikasi economies of

scale

6 Interkoneksi

aplikasi bersifat

point-to-point

Interkoneksi

tidak bersifat

point-to-point

untuk

memudahkan

perubahan dan

pemeliharaan

Interkoneksi

melalui

middleware

ESB

7 Interkoneksi dan

layanan antar

aplikasi hanya

memperhatikan

aplikasi tersebut

Layanan

aplikasi dibuat

reusable dan

dapat diakses

oleh aplikasi

lain

Desain aplikasi

berbasis SOA

ESB

8 Belum ada

sistem data

warehouse dan

sistem business

intelligence

Mempunyai

perencanaan

implementasi

sistem data

warehouse dan

business

intelligence

Desain

implementasi data

warehouse dan

business

intelligence

Data

warehouse dan

business

intelligence

9 Belum ada

sistem CRM

Mempunyai

perencanaan

implementasi

sistem CRM

Desain

implementasi

sistem CRM

Sistem CRM

10 Belum ada dan

dibutuhkan

mobile access

untuk IBE dan

IBE dapat

diakses melalui

mobile device

beserta fitur

Pengembangan

mobile application

untuk IBE dan

check-in

• Mobile-IBE

• Mobile

check-in

• ESB

81


N

o


check-in untuk check-in • PSS service

11 Check-in hanya

dapat dilakukan

melalui check-in

counter atau

perwakilan

airline di kota

keberangkatan

Belum ada dan

dibutuhkan

mobile access

untuk IBE dan

check-in

Check-in dapat

dilakukan dari

mana saja selain

melalui check-in

counter atau

kantor

perwakilan

airline

Check-in melalui

web secara online,

melalui mobile

device dan melalui

sistem check-in

mandiri di airport

• Web Check-

in

• Mobile

Check-in

• KIOSK

check-in

system di

airport

12 Belum ada dan

dibutuhkan

fungsi pay for

purchase item

saat penumpang

melakukan

booking

Penambahan

fungsi pay for

purhase item

pada IBE-B2C

Pengembangan

fungsi pay for

purchase item pada

IBE-B2C

• IBE-B2C

• PSS service

13 Adanya

penerapan yang

tidak sesuai

dengan industry

best practice

pada klien

tertentu

sehingga

membutuhkan

effort/resources

Rule pada

deposit

management

dapat

mengakomodir

bisnis proses

secara fleksibel

Pemisahan modul

deposit

management agar

bersifat modular

dengan

pengembangan

konfigurasi rule

yang fleksibel

Deposit

Management

82


N

o


besar contohnya

pada B2T

deposit

management

14 Belum ada dan

dibutuhkan API

untuk kerjasama

dengan third

party seperti

online travel

agent (OTA)

Tersedianya API

yang dapat

diakses untuk

kebutuhan OTA

Pengembangan

API berupa web

service yang dapat

diakses secara lokal

dan public melalui

internet

• PSS

Service

• ESB

• Open

Travel

Alliance

(OTA)API

15 Data

kosong/fungsi

ticketing IBE

kadang

mengalami

masalah pada

pembayaran

credit card

Menjamin

integritas data,

yaitu jika

pembayaran

dilakukan maka

proses ticketing

diharuskan

selesai

Proses payment dan

ticketing menjadi

satu kesatuan yang

bersifat atomic.

Proses untuk

menjadikan atomic

meliputi proses

pembayaran ke

payment gateway

dan proses ticketing

di PSS

• IBE-B2C

16 Data manifest

tidak terkirim

Penyederhanaan

proses

pembuatan

laporan manifest

Layanan di PSS

yang dapat

digunakan untuk

mendapatkan

manifest untuk tiap

jadwal

penerbangan

PSS Service

83


N

o


17 Terjadi data

discrepancy

antara data

Compass (PSS)

dengan B2T

Data antara PSS

dan B2T

konsisten

Penyederhanaan

model konektivitas

• PSS Service

• ESB

18 Kesulitan

menentukan

patokan harga

sesuai dengan

segmen pasar

dan timing yang

menjadi target

Proses

penentuan harga

dengan bantuan

sistem

Implementasi

aplikasi aplikasi

revenue

management

system

Revenue

Management

System

19 Tidak

tersedianya data

statistik pejualan

Data penjualan

tersedia dan

dapat dilihat

statistiknya

untuk analisis

lebih lanjut guna

melakukan

pengembangan

pasar

Menyimpan data

operasional untuk

kebutuhan analisis

dan dari data

tersebut dapat

dibentuk statistik

dengan grafik yang

sesuai

• Data

warehouse

• Business

Intelligence

20 Agen tidak bisa

melakukan

payment

Otomatisasi

proses registrasi

agen pada IBE-

B2T untuk

mengurangi

kesalahan SOP

Pengembangan

modul auto agent

registration pada

B2T dan service

yang bersesuaian

pada PSS

• PSS Service

• IBE-B2T

21 B2T dan B2C

tidak dapat

search

Penyederhanaan

proses

komunikasi ke

Pengembangan

PSS Service berupa

web service dengan

• PSS Service

• Monitoring

system

84


N

o


availability PSS pre-defined input

22 Komisi kadang

tidak masuk

Penyederhanaan

proses

komunikasi ke

PSS

Pengembangan

PSS Service berupa

web service untuk

mengurangi jumlah

komunikasi ke PSS

• PSS

Service

• Robotic

auto closing

ticket

23 Booking kadang

tidak

mendapatkan

ticketing time

limit

Otomatisasi

proses registrasi

agen pada IBE-

B2T untuk

mengurangi

kesalahan SOP

Pengembangan

modul auto agent

registration pada

B2T dan service

yang bersesuaian

pada PSS

• PSS Service

• IBE-B2T

24 B2T system

tidak bisa

diakses

Penyederhanaan

proses

komunikasi ke

PSS

Pengembangan

PSS Service berupa

web service untuk

mengurangi jumlah

komunikasi ke PSS

• PSS

Service

25 Koneksi

jaringan di

daerah yang

kurang baik

sehingga

menghambat

sistem

Sistem dapat

diakses diakses

dengan baik

oleh agen di

daerah

• Perbaikan

koneksi

jaringan dan

efisiensi sistem

B2T agar

mentransfer

data lebih

sedikit

• Pengembangan

sistem dengan

komunikasi data

yang efisien

• IBE-B2T

• SMS

booking

26 Sales distributon Sales Implementasi • IBE-B2T

85


N

o


harus terhubung

ke banyak

channel dan

payment

distribution

mempunyai

banyak channel

dan metode

payment

beragam

distributionchannel

dan didukung

payment channel

yang beragam

• OTA API

• Mobile

reservation

27 Optimizer untuk

crew

management

Penjadwalan

crew secara

otomatis,

pairing dan

assignment

dapat

dioptimalkan

Implementasi

aplikasi optimizer

untuk crew

management

Crew

management

optimizer

system

28 Rotation

optimizer untuk

aircraft

management

Aircraft

management

dapat lebih

optimal dan

aircraft tidak

terlalu lama idle

Implementasi

aplikasi rotation

optimizer untuk

aircraft

management

Rotation

optimizer

system

29 Komunikasi

aplikasi di flight

ops memerlukan

suatu gateway

yang terkadang

komunikasinya

tidak stabil

Komunikasi dari

dan ke aplikasi

flight ops

menjadi stabil

Modernisasi pola

komunikasi

• ESB

• Message

Queue

Server

30 Tidak bisa

mencetak flight

plan.

Flight plan

dapat dicetak

dengan baik

Dapat dijamin

bahwa message

yang dikirim

sampai dengan baik

sehingga flight plan

• ESB

• Message

Queue

Server

86


N

o


dapat dicetak

5.3.2 Pemetaan solusi permasalahan terhadap prinsip arsitektur

Pola solusi yang ada dalam penerapannya harus mengikuti prinsip-prinsip

arsitektur yang ditetapkan. Pemetaan solusi permasalahan terhadap prinsip

arsitektur disajikan dalam tabel 5.6.

Tabel 5.6 Pemetaan solusi permasalahan terhadap prinsip arsitektur No Pola Solusi Prinsip Arsitektur

1 • Efisiensi model koneksi,

menghilangkan layer yang tidak efisien

• Penerapan SOA

• Design for change

• Maximize agility and

flexibility of application

and Infrastructure

• Service orientation

• Interoperability

2 Implementasi sistem monitoring untuk

aplikasi dan infrastruktur

• Kemudahan penggunaan

• Business continuity

3 Pengembangan GUI untuk PSS berbasis

web sehingga bersifat thin client

• Accessibility




and Infrastructure

• Secure Information

• Penggunaan kembali

• Business Continuity

• Corporate data model


• Common use application

4 Desain infrastruktur berbasis SOA • Design for change


87


No Pola Solusi Prinsip Arsitektur


and Infrastructure

• Service Orientation



5 Desain aplikasi berbasis SOA dengan

pengunaan layanan bersama




and Infrastructure







6 Interkoneksi melalui middleware • Design for change



and Infrastructure







7 Desain aplikasi berbasis SOA • Design for change



and Infrastructure


88








8 Desain implementasi data warehouse • Secure Information



9 Desain implementasi sistem business

intelligence



10 Desain implementasi sistem CRM • Secure Information




11 Pengembangan mobile application untuk

IBE dan check-in

• Accessibility




and Infrastructure




• User management





12 Check-in melalui web secara online,

melalui mobile device dan melalui sistem

check-in mandiri di airport

• Accessibility



89




and Infrastructure




• User management





13 Pengembangan fungsi pay for purchase

item pada IBE-B2C






14 Pemisahan modul deposit management

agar bersifat modular dengan

pengembangan konfigurasi rule yang

fleksibel





• User management





15 Pengembangan API berupa web service

yang dapat diakses secara lokal dan

public melalui internet




and Infrastructure



90







16 Proses payment dan ticketing menjadi

satu kesatuan yang bersifat atomic.

Proses untuk menjadikan atomic meliputi

proses pembayaran ke payment gateway

dan proses ticketing di PSS



• Corporate Data model


17 Layanan di PSS yang dapat digunakan

untuk mendapatkan manifest untuk tiap

jadwal penerbangan





18 Penyederhanaan model konektivitas • Maximize agility and


and Infrastructure


19 Implementasi aplikasi aplikasi yield

management system




and Infrastructure





• User management





91



20 Menyimpan data operasional untuk

kebutuhan analisis dan dari data tersebut

dapat dibentuk statistik dengan grafik

yang sesuai

• Accessibility





21 Pengembangan modul auto agent

registration pada B2T dan service yang

bersesuaian pada PSS




• User management




22 Pengembangan PSS Service berupa web

service dengan pre-defined input






service untuk mengurangi jumlah

komunikasi ke PSS




and Infrastructure







24 Pengembangan modul auto agent

registration pada B2T dan service yang

bersesuaian pada PSS




• User management

92







service untuk mengurangi jumlah

komunikasi ke PSS




and Infrastructure







26 • Perbaikan koneksi jaringan dan

efisiensi sistem B2T agar mentransfer

data lebih sedikit

• Pengembangan sistem dengan

komunikasi data yang efisien




and Infrastructure







27 Implementasi beragam distribution

channel dan didukung payment channel

yang beragam

• Accessibility




and Infrastructure



93





• User management





28 Implementasi aplikasi optimizer untuk

crew management



and Infrastructure



29 Implementasi aplikasi rotation optimizer

untuk aircraft management




and Infrastructure




30 Modernisasi pola komunikasi • Maximize agility and


and Infrastructure




31 Dapat dijamin bahwa message yang

dikirm sampai dengan baik sehingga

flight plan dapat dicetak



and Infrastructure


94


5.3.3 Visi Arsitektur

Iterasi pertama dari proses TOGAF ADM didapatkan kondisi saat ini sesuai

dengan tahapan-tahapan TOGAF ADM. Beberapa hal yang telah dibuat antara

lain diagram value chain, daftar pemetaan stakeholder, kemudian dilanjutkan

dengan arsitektur bisnis, data, aplikasi dan teknologi dari kondisi saat ini. Tahap

selanjutnya adalah iterasi kedua dari proses TOGAF ADM yang dimulai dari visi

arsitektur dengan memodelkan diagram konsep solusi.

Diagram konsep solusi memberikan gambaran secara umum dari arsitektur target

dengan perubahan-perubahan yang diperlukan. Diagram konsep solusi disajikan

dalam gambar 5.6.

Passenger Travel Agent Branch Office

Check-in Counter

Operation


Network Planning and Scheduling System



Commercial and Business

PricingNetwork Planning

Aircraft ManagementCrew Management

PSS

Booking, Ticketing

IBE-B2C IBE-B2T PSS-GUI

Booking, Ticketing

Booking, Ticketing

Booking, Ticketing

Online Travel Agent

Mobile Check-in KIOSK PSS-GUIWeb Check-in

Passenger

Check-in Check-in

Reservation, Ticketing, Departure Control

Managamenet

Payment Gateway

Optimizer Optimizer

E-Briefing

Crew

Briefing

Ops ControlCFD

FOQA

AIRCOM

Sentinel

Ops Control

Flight Operation

Meal Monitoring

FFP

FIDS View FlightSchedule

Customer LoyaltyBranch Office

Check-in

Mobile-IBE

PSS-Service

PSS-Service

CRM

Customer relation

Gambar 5.6 Diagram konsep solusi

Diagram konsep solusi yang dibangun dikembangkan berdasarkan arsitektur

baseline dan juga pola solusi untuk mengatasi permasalahan yang ada. Dari

95


diagram konsep solusi tampak bahwa peran SI/TI tidak bisa dilepaskan dari proses

bisnis yang ada. Saat ini penetrasi SI/TI dalam industri airline telah sedemikian

besar dan meliputi berbagai proses bisnis yang ada.

Dalam diagram konsep solusi digambarkan bahwa calon penumpang dapat

melakukan booking dan ticketing dengan berbagai cara. Hal ini dapat

dimungkinkan dengan perluasan distribution channel dari airline yang didukung

dengan pemanfaatan SI/TI. Dalam hal ini calon penumpang dapat melakukan

booking dan ticketing dengan melalui 4 cara yaitu: 1) agen perjalanan/travel

agent; 2) kantor perwakilan airline/branch office; 3) direct purchase melalui IBE-

B2C; dan 4) melalui online travel agent yang merupakan intermediaries yang

sifatnya online. Dengan berbagai distribution channel yang ada, hal ini akan

memperluas jangkauan penjualan bagi airline. Beberapa hal yang menjadi catatan

adalah bahwa beberapa model penjualan dapat sepenuhnya dibuat menjadi digital

dimulai dari proses pencarian jadwal, pengecekan harga sampai dengan proses

booking dan ticketing. Dengen penetrasi internet yang semakin membesar, hal ini

dapat menjadi kelebihan tersendiri.

Kemudian dalam proses pre-flight, calon penumpang juga diberi kemudahan

dengan berbagai cara pilihan melakukan check-in. Terdapat 5 cara untuk

melakukan check-in, yaitu: 1) melalui cara konvensional dengan melakukan

check-in di check-in counter di bandara keberangkatan; 2) melalui city check-in di

kantor perwakilan airline di kota keberangkatan; 3) melalui KIOSK, yaitu check-

in secara mandiri di bandara keberangkatan; 4) melalui web check-in; dan 5)

melalui mobile check-in. Pilihan metode check-in yang beragam memberikan

kemudahan dan diharapkan dapat memberi kenyamanan bagi calon penumpang

selain juga dapat membuat waktu calon penumpang menjadi lebih efisien dalam

rangkaian perjalanannya.

Diagram konsep solusi pada tahap ini masih bersifat umum tetapi menjadi

gambaran solusi yang akan dijelaskan lebih detai pada tahap-tahap berikutnya.

Diagram konsep solusi dapat menjadi acuan umum dari sisi proses bisnis dan

solusi SI/TI yang ada.

96


5.3.4 Arsitektur Sistem Informasi

Arsitektur sistem informasi pada iterasi ke-2 TOGAF ADM akan memuat solusi

dari permasalahan yang telah diidentifikasi. Perubahan-perubahan yang ada akan

tergambar dalam arsitektur data dan arsitektur aplikasi berikut ini:

5.3.4.1 Arsitektur Data

Arsitektur data pada iterasi ke-2 kali ini memuat beberapa data baru yang

dibutuhkan oleh beberapa aplikasi baru sebagai solusi dari permasalahan yang

ada. Arsitektur data iterasi ke-2 sebagai arsitektur target disajikan pada gambar

5.7.





PSS

OTAIBE-B2C

FIDS Meal Monitoring CFD

FOQA

E-Briefing

AIRCOM Sentinel

Ops Control

Cargo Solution

FFP

Revenue Accounting Systen

Sales Dashboard

SSIM

ASM/SSM

Crew Data and Schedule

APIS Crew

Blackbox Data Fligt LogACARS Data

FindAvailability

andFare Data

PassengerBooking and Ticketing

Data

FlightInformation

Checked-InPassenger

Ticket Sales and Flown

Passenger Flown Data

Fare Data

Flight Plan

PNR and Ticket

APIS Pax

Baggage Data

Flight Connection Data

PSS GUI IBE Mobile

SMS Booking IBE-B2T

Deposit Management

Deposit Data

Mobile Check-in

KIOSK

Web Check-in

PSS GUI

Check-inData

CRM

Customer FIle

Gambar 5.7 Target arsitektur data

97


Dari gambar 5.7 tampak bahwa terdapat kesenjangan dengan arsistektur data pada

iterasi pertama. Penjelasan lebih lanjut keterangan tentang penambahan data pada

arsitektur data disajikan dalam tabel 5.7.

Tabel 5.7 Keterangan target arsitektur data No Data Keterangan

1 Deposit data Deposit data adalah informasi untuk kebutuhan deposit

management. Deposit data berisikan jumlah deposit

yang didepositkan oleh agen perjalanan dan jumlah

tersebut akan dikurangi jika agen melakukan ticketing.

Dengan demikian agen perjalanan akan memerlukan

sejumlah deposit tertentu lebih dahulu sebelum dapat

melakukan ticketing.

2 Check-in data Check-in data adalah data yang berisikan informasi

untuk keperluan check-in. Data ini digunakan oleh

aplikasi yang berhubungan dengan proses check-in

seperti aplikasi web check-in, mobile check-in, KIOSK

dan PSS GUI.

5.3.4.2 Arsitektur Aplikasi

Arsitektur aplikasi pada iterasi kedua ini juga telah mengakomodir solusi-solusi

dari permasalahan yang ada. Arsitektur aplikasi ini disajikan dalam gambar 5.8.

Jika dilihat lebih detail beberapa solusi SI/TI memungkinkan adanya sub-proses

bisnis yang baru. Dengan demikian adanya solusi SI/TI telah menjadi enabler

bagi model bisnis airline. Hal ini tampak misalnya dalam solusi distribution

channel. Dengan adanya solusi SI/TI maka dimungkinkan adanya distribution

channel yang baru seperti IBE-mobile dan implementasi online travel agent.

Solusi lain yang juga merupakan enabler adalah web check-in dan mobile check-

in. Solusi web dan mobile check-in memungkinkan calon penumpang melakukan

check-in dimana saja kapan saja tanpa harus mendatangi bandara atau kantor

perwakilan airline.

98



Pricing

Network Planning

Crew Management

Reservation

Ticketing

Check-in

Departure Control

Flight Operation

Catering Management


Revenue Management



E-Briefing

PSS

PSS

PSS

PSS

PSSIBE-B2C

IBE-B2T


FFP

Meal Monitoring

IBE-B2C

IBE-B2T

Revenue Accounting System

PSS


Flight Connections

PSS

Proses Bisnis Inti

Aircraft management


Internal Audit

AIRCOM

Ops Control Sentinel

FOQA

Sales Dashboard

FIDS

CFD

Cargo Management

Cargo solutions

IBE-Mobile

OTA-API

PSS GUI

PSS GUI Web Check-in

Mobile Check-in

KIOSK

PSS GUI

Deposit Management

OTA-API

IBE-Mobile

SMS Booking

CRM


Gambar 5.8 Target arsitektur aplikasi

Dengan diakomodirnya solusi SI/TI untuk mengatasi permasalahan yang ada,

mengakibatkan adanya penambahan jika dibandingkan dengan arsitektur aplikasi

sebelumnya. Keterangan mengenai aplikasi-aplikasi tersebut disajikan pada tabel

5.8.

Tabel 5.8 Portofolio sistem informasi No Aplikasi Keterangan

1 PSS GUI PSS GUI merupakan aplikasi klien yang pada

dasarnya adalah sebagai wrapper bagi PSS agar

dapet diakses melalui GUI. Hal ini karena pada

saat ini PSS masih harus diakses melalui console

dan menurut salah satu stakeholder (CTO)

dibutuhkan akses berupa PSS GUI agar PSS untuk

menghasilkan nilai jual yang lebik. PSS GUI

nantinya tetap akan mengakomodir pola akses

99


No Aplikasi Keterangan

sebelumnya yaitu melalui console yang dapat

diakses melalui web. Dengan demikian pengguna

dapat memilih menggunakan PSS GUI melalui

pola mouse click atau melalui entry pada web

console.

2 OTA-API OTA-API adalah API (application programming

interface) untuk mendukung fungsi online travel

agent. Hal ini untuk memenuhi kebutuhan airline

sebagai bentuk perluasan distribution channel

airline. OTA-API adalah berupa layanan fungsi

reservasi dan ticketing yang dapat diakses oleh

aplikasi yang dimiliki oleh online travel agent.

Dengan adanya OTA-API maka dimungkinkan

adanya kerjasama dengan intermediaries, dalam

hal ini adalah OTA sehingga bagi airline

diharapkan hal ini akan memberikan manfaat.

3 IBE-Mobile IBE-Mobile adalah aplikasi IBE yang dapat

diakses melalui mobile. Mobile disini berarti

beberapa hal yaitu: 1) mobile web; dan 2)

nativemobile. Dengan IBE-Mobile maka calon

penumpang dapat melakukan reservasi dan

ticketing dimana saja dan kapan saja.

4 SMS Booking SMS booking adalah aplikasi yang memungkinkan

proses reservasi dilakukan melalui SMS. Hal ini

bertujuan untuk membuat proses reservasi menjadi

lebih efisien dalam hal lalu lintas data melalui

jaringan internet. Dengan demikian proses

reservasi dapat dilakukan meskipun di daerah

yang belum memiliki infrastruktur jaringan

internet yang cukup baik.

5 Deposit Management Deposit management adalah aplikasi yang

100


No Aplikasi Keterangan

mengolah deposit untuk keperluan agen

perjalanan. Saat ini modul deposit management

masih terintegrasi didalam aplikasi IBE-B2T dan

hal tersebut tidak memberikan fleksibilitas

sehingga perlu dilakukan perbaikan dan membuat

aplikasi deposit management yang berdiri sendiri.

6 Mobile Check-in Mobilecheck-in adalah aplikasi yang bersifat

mobile serupa dengan IBE-Mobile namun

memiliki fungsi yang berbeda. Mobile check-in

lebih dikhususkan untuk keperluan check-in dan

diperuntukkan bagi penumpang yang akan

melakukan check-in.

7 KIOSK KIOSK adalah aplikasi yang dapat digunakan di

airport agar penumpang dapat melakukan check-

in secara mandiri. KIOSK akan terhubung ke PSS

untuk melakukan proses check-in

8 Web Check-in Web check-in adalah aplikasi yang serupa dengan

mobile check-in, namun akses dilakukan melalui

webbrowser. Web check-in juga terhubung ke

PSS untuk melakukan proses check-in.

9 Sistem CRM Sistem CRM adalah sistem yang digunakan untuk

memaksimalkan penjualan terhadap pelanggan

yang sudah ada dan mendorong mereka untuk

tetap menggunakan layanan yang disedikan,

dalam hal ini airline, secara berkelanjutan.

5.3.5 Arsitektur Teknologi

Arsitektur teknologi dibuat agar apa yang telah di-desain pada tahap sebelumnya

dapat diaplikasikan dan mewujudkan apa yang terdapat pada visi arsitektur.

101


Arsitektur teknologi juga sebagai implementasi dari request of architecture work

dari stakeholder. Berikut hasil dan pembahasan dari arsitektur teknologi:

5.3.5.1 Landscape Aplikasi

Landscape aplikasi diilustrasikan dalam gambar 5.9. Selain menggambarkan

aplikasi-aplikasi yang ada landscape aplikasi juga menggambarkan hal-hal yang

dipersyaratkan oleh prinsip-prinsip arsitektur sehingga gambaran mengenai

landscape aplikasi secara keseluruhan menjadi lebih jelas.

Dipersyaratkan oleh prinsip-prinsip arsitektur

WEB Client

RMS

PSS

Network Planning & Scheduling System

IBE-B2C

Deposit Management

KIOSK

Web Check-in

Enterprise

Application Integration

Desktop Client

Iden

tity

Man

agem

ent

Virt

ualiz

atio

n

Mobile Client (Smartphone)


IBE-B2T

IBE-Mobile

Ops Control

Mobile Check-in

FOQA

CFD

E-Briefing


SMS-Booking

PSS GUI

OTA-API

FIDS

Meal Monitoring

AIRCOM

Sentinel

FFP Security

Corporate D

ata Model

Mon

itorin

g

CRM

Gambar 5.9 Landscape aplikasi

102


5.3.5.2 Perspektif Arsitektur

Dalam perspektif arsitektur dipetakan hubungan antara landscape aplikasi dengan

TOGAF technical reference model (TRM). Pemetaan tersebut diilustrasikan

dalam gambar 5.10. Dalam TRM terdapat tiga entitas yaitu: 1) aplikasi; 2)

platform aplikasi; dan 3) infrastruktur komunikasi. Aplikasi terbagi lagi kedalam

aplikasi bisnis dan aplikasi infrastruktur. Aplikasi bisnis akan dipetakan terhadap

landscape aplikasi ke aplikasi yang sifatnya adalah untuk melakukan bisnis

sedangkan aplikasi infrastruktur dipetakan ke aplikasi yang bertindak sebagai

infrastruktur bagi aplikasi bisnis.

Platform aplikasi dapat dipetakan ke landscape aplikasi untuk aplikasi-aplikasi

yang bertindak sebagai platform dimana aplikasi bisnis akan berjalan diatasnya.

Dipersyaratkan oleh prinsip-prinsip arsitektur

WEB Client

Enterprise


Desktop Client

Iden

tity

Man

agem

ent

Virt

ualiz

atio

n


Mon

itorin

g

Security

Corporate D

ata Model

Infrastructure Application

Business Application

Application Programming Interface

Softw

are Engineering

Security

Transaction Processing

International O

perations

Data M

anagement

Graphics and Im

ages

Operating System Services

Communications Infrastructure Interface

Communication Infrastructure

Location and Directory

User Interface

Data Interchange

Network Services

Ssytem

and Netw

ork M

anagement

RMS

PSS


IBE-B2C

Deposit Management

KIOSK

Web Check-in


IBE-B2T

IBE-Mobile

Ops Control

Mobile Check-in

FOQA

CFD

E-Briefing


SMS-Booking

PSS GUI

OTA-API

FIDS

Meal Monitoring

AIRCOM

Sentinel

FFP

CRM

Gambar 5.10 Perspektif arsitektur

5.3.5.3 Arsitektur Gabungan

Dalam arsitektur gabungan pemetaan yang telah dilakukan pada tahap sebelumnya

dibentuk menjadi suatu arsitektur gabungan. Arsitektur gabungan ini masih

berbasiskan kepada TRM hanya saja sudah merupakan penggabungan dari

landscape aplikasi. Arsitektur gabungan diilustrasikan pada gambar 5.11.

103


Pemilihan teknologi juga dilakukan pada tahap ini. Basis dari pemilihan

teknologi adalah berdasarkan prinsip-prinsip arsitektur yang ada. Tabel 5.9 akan

menunjukkan hubungan antara pemilihan teknologi dan prinsip-prinsip arsitektur.

RMS

PSS


IBE-B2C

Deposit Management

KIOSK

Web Check-in


IBE-B2T

IBE-Mobile

Ops Control

Mobile Check-in

FOQA

CFD

E-Briefing


SMS-Booking

PSS GUI

OTA-API

FIDS

Meal Monitoring

AIRCOM

Sentinel

FFP

CRM

WEB Client

Enterprise


Desktop Client

Iden

tity

Man

agem

ent

Virt

ualiz

atio

n


Security

Corporate D

ata Model

Mon

itorin

g

Operating System Services

Communication Infrastructure

Network Services

ESB

Enterprise Firewall, SSL

·∙ HTML·∙ Native Desktop·∙ Native Mobile

·∙ Web Service (SOAP/REST)

·∙ Messaging·∙ File Transfer

·∙ Linux Server·∙ Windows Server·∙ Z/OS

VMware

Zenoss

LDAP

·∙ Desktop Windows·∙ Mobile Client

(Android/IOS/Windows Phone)

Mail Server

Database Server

Gambar 5.11 Arsitektur gabungan

Tabel 5.9 Pemetaan teknologi dan prinsip arsitektur No Kategori Teknologi Prinsip Arsitektur

1 Enterprise

Application

Integration

Web service

(SOAP/REST)

Service Orientation, design for

change, interoperability

Messaging Service Orientation, design for

change

File transfer Service Orientation, design for

change, Interoperability

Database adapter Service Orientation, design for

change, Interoperability

2 Security Enterprise firewall Secure Information

SSL Secure Information

104


No Kategori Teknologi Prinsip Arsitektur

3 Web client HTML Design for change

4 Mobile client Native mobile Design for change

5 Desktop client Native desktop Design for change

6 Corporate data

model

Database server Corporate data model

7 Operating

system services

Linux Server,

Windows Server,

Z/OS, Windows

desktop, Android,

IOS, Windows

Phone

Penggunaan kembali

8 Network

services

Mail server

9 Virtualization VMware Maximize agility and flexibility of

application and Infrastructure,

Penggunaan kembali

10 Monitoring Zenoss Penggunaan kembali

11 Identity

Management

LDAP Identity management

5.3.5.4 Peta Interoperabilitas

Peta interoperabilitas yang terdapat pada gambar 5.12 menyajikan aliran informasi

yang antar aplikasi. Peta interoperabilitas ini selaras dengan arsitektur data yang

ada pada pembahasan sebelumnya. Dari peta interoperabilitas dapat diidentifikasi

aplikasi mana saja yang mempunyai aliran data dan perlu diintegrasikan.

Pembahasan selanjutnya dari hal tersebut adalah mekanisme integrasi yang tepat.

Mekanisme integrasi yang tepat dilakukan dengan memperhatikan efektivitas,

efisiensi dan prinsip-prinsip arsitektur yang telah tertuang dalam arsitektur

gabungan pada pembahasan sebelumnya.

105


Web Client Desktop ClientMobile ClientN

etwork S

ecurity

RMS

Network Planning & Scheduling

System

IBE-B2C

Deposit Management

FOQA

Web Check-in

Aircraft Management

System

IBE-B2T IBE-Mobile


Mobile Check-in

PSS GUI

CFD

FIDS

Ops Control

SMS-Booking

AIRCOM

OTA-API

E-Briefing

Meal Monitoring

KIOSK

Sentinel

FFP

Web Client Desktop ClientMobile Client

PSSCRM

Gambar 5.12 Peta interoperabilitas

5.3.5.5 Mekanisme integrasi dan platform arsitektur teknologi

Dari peta interoperabilitas didapat bahwa terdapat aliran data antar aplikasi.

Aliran data terjadi karena terdapat aplikasi yang membutuhkan data dari aplikasi

lainnya untuk menjalankan fungsi bisnis seperti yang terdapat pada arsitektur data.

Dengan memperhatikan arsitektur gabungan yang telah dibuat yang didalamnya

terdapat platform aplikasi maka dapat didefinisikan mekanisme integrasi antar

aplikasi. Mekanisme integrasi hanya didefinisikan untuk aplikasi yang

mempunyai aliran data/interoperabilitas dan untuk lebih lengkapnya terdapat pada

tabel 5.10.

106


Tabel 5.10 Mekanisme integrasi Deposit

Mana-

gement

PSS Aircraft

Managemen

t System

E-Briefing Ops

Control

CR

M

IBE-B2C SOAP

IBE-B2T SOAP SOAP

SMS-

Booking

REST

IBE-Mobile REST

RMS MQ Network Planning & Scheduling System

FTP


MQ FTP


Database FTP

PSS-GUI SOAP KIOSK SOAP Mobile Check-in

REST

FIDS SOAP Web Check-in SOAP Meal Monitoring

SOAP

FFP FTP FTP CFD SOAP OTA SOAP

Dari tabel didapatkan terdapat beberapa pola mekanisme integrasi yang ada. Pola

mekanisme integrasi tersebut adalah: 1) SOAP; 2) REST; 3) MQ; 4) FTP; dan 5)

JDBC. Dari pola integrasi yang ada maka dibuat suatu platform arsitektur

107


teknologi. Untuk lebih lengkapnya platform arsitektur teknologi dapat dilihat

pada gambar 5.13.

Platform arsitektur teknologi yang diilustrasikan pada gambar 5.13

menggambarkan platform teknologi yang digunakan untuk setiap layer aplikasi.

Layer aplikasi terdiri atas: 1) client interface; 2) network; 3) presentation; 4)

application; 5) application integration; dan 6) database.

Client Interface Network Presentation Application Application

IntegrationDatabase

Windows LANRMS/PROS




PSS

IBE- B2C

IBE-B2T

Meal Monitoring

Ops Control

FOQA

E-Briefing

AIRCOM

Sentinel

CRM

CFD

FIDS

PSS GUI

OTA-API

IBE-Mobile

SMS BookingDeposit

Management

Mobile Check-in

KIOSK

Web Check-in

Windows

Windows

Windows

LAN

LAN

LAN

.NET Server

.NET Server

.NET Server

.NET Server

Browser

Browser

Browser

Windows

Windows

Browser

Windows

Browser

Browser

Browser

Browser

Mobile

Browser

Mobile

Mobile

Windows

Mobile

Revenue

Internet

Internet

LAN

LAN

LAN

LAN

LAN

LAN/Internet

LAN

LAN

Internet

Internet

Internet

Internet

Internet

Internet

LAN

Internet

Java Application Server


Web Server & PHP

.NET Server

Schedule

Ops

Crew

TPF

B2C

B2T

B2C

Flight

Blackbox

Web Server & PHP

Windows Message


Web Server & PHP Flight Dispatch

Web Server & PHP



Java Application Server Deposit

Windows

Windows Flight Event

SOAP

SOAP

REST

MQ

FTP

FTP

FTP


DB Conn





sMile/FFP Browser LAN/Internet Java Application Server Loyalty

FTP Customer

Data Warehouse

PSS Offline

Gambar 5.13 Platform Arsitektur Teknologi

108


Berikut disajikan penjelasan lebih detail tentang platform arsitektur teknologi:

1. Client interface. Platform arsitektur teknologi pada client interface terbagi

menjadi beberapa pola. Hal ini menyesuaikan dengan aplikasi-aplikasi yang

ada yang ditangani oleh Asyst. Beberapa pola client interface yang ada yaitu:

• Windows, yaitu berupa aplikasi desktop berbasis windows

• Browser, yaitu clientinterface yang diakses menggunakan web browser

• Mobile, yaitu client interface yang diakses melalui mobile device. Hal ini

terbagi lagi dalam beberapa pola yaitu mobile web (browser pada mobile

device), native clientAndroid, IOS, dan Windows Phone.

2. Network. Network mendefinisikan melalui pola jaringan seperti apa aplikasi

akan diakses. Untuk hal ini beberapa aplikasi ditargetkan dapat diakses

melalui LAN dan beberapa lainnya melalui jaringan internet seperti pada

gambar.

3. Presentation. Presentation adalah teknologi yang digunakan untuk

menyajikan user interface aplikasike end user..

4. Application. Merupakan layer dari aplikasi yang berisikan business logic.

5. Application integration. Adalah bagian integration layer dari aplikasi. Layer

ini berhubungan dengan aplikasi lain untuk memenuhi kebutuhan bisnis.

6. Database. Merupakan persistence layer dan tempat data disimpan.

Langkah selanjutnya adalah menentukan integrasi yang optimal untuk diterapkan.

Dari tabel 5.10 dan gambar 5.13 tampak bahwa mekanisme integrasi melibatkan

beberapa pola yaitu:

1. SOAP (simple object access protocol)

SOAP adalah salah satu protokol yang dapat digunakan untuk implementasi

web service. Penggunaan web service berbasis SOAP menggunakan format

XML dan hal ini memberikan fleksibilitas karena sifatnya yang tidak

bergantung pada platform sistem operasi atau bahasa pemrograman tertentu.

Karena hal tersebut dan sesuai dengan prinsip-prinsip arsitektur yang telah

ditetapkan (service orientation, interoperability) maka mekanisme integrasi

dengan web service menggunakan protokol SOAP menjadi pilihan pertama

109


sebagai mekanisme integrasi kecuali terdapat persyaratan khusus lain atau

terdapat mekanisme integrasi lain yang lebih sesuai untuk digunakan.

2. REST

REST adalah salah satu metode web service yang dapat digunakan selain

SOAP. REST lebih sesuai digunakan jika bandwith internet yang digunakan

terbatas. Karena hal tersebut REST sesuai dengan mekanisme integrasi yang

berhubungan dengan aplikasi mobile dimana penggunaan bandwith internet

harus seefisien mungkin.

3. MQ

Mekanisme integrasi lain yang digunakan adalah melalui message queue

(MQ). MQ digunakan untuk mekanisme integrasi dengan tipe messaging.

MQ dapat digunakan untuk mekanisme integrasi yang bersifat

unsynchronized.Dalam hal ini pengirim data hanya menyampaikan dan tidak

menunggu respon dari penerima data.

4. FTP

Untuk mekanisme integrasi yang melibatkan data dalam jumlah besar maka

lebih efektif digunakan pengiriman data dalam suatu file. File ini dapat

berisikan data rekapitulasi yang dikirimkan dalam periode yang cukup

panjang misalnya 1 kali dalam 1 hari.

5. Database adapter

Beberapa aplikasi masih melakukan penggunaan data bersama melalui akses

ke database. Akses ke database dilakukan melalui database adapter secara

native bergantung pada platform pemrograman yang digunakan (contoh:

JDBC pada Java).

Dari 5 jenis mekanisme integrasi yang telah didefinisikan perlu dilakukan kembali

evaluasi agar dihasilkan mekanisme integrasi yang bersifat menyeluruh pada level

enterprise dan didapat suatu enterprise application integration (EAI).

Lebih jauh lagi menurut Soomro dan Amrar (2012) bahwa sistem informasi yang

ada pada suatu organisasi dapat berbasiskan pada teknologi baru dan lama dengan

110


platform teknologi, basis data dan bahasa pemrograman yang berbeda yang akan

semakin menambah kompleksitas. Disebutkan juga bahwa sekitar 35% dari

waktu pengembangan sistem dan 30% dari biaya, digunakan untuk membangun

interface, titik integrasi dan juga data source untuk kebutuhan integrasi. Dengan

demikian perlu dibuat suatu mekanisme integrasi secara menyeluruh berupa

enterprice application integration (EAI) dengan memperhatikan prinsip-prinsip

arsitektur yang ada.

Dua pendekatan yang mungkin dilakukan untuk mekanisme integrasi secara

keseluruhan adalah dengan mekanisme point-to-point dan dengan implementasi

enterprise service bus (ESB). Tabel 5.11 menyajikan perbandingan jika

mekanisme integrasi dilakukan melalui point-to-point dan dengan implementasi

ESB.

Pada tabel 5.11 didefinisikan 8 kategori untuk pemilihan mekanisme integrasi.

Dari 8 kategori yang ada, ESB lebih baik pada 7 kategori dan point-to-point lebih

baik pada 1 kategori. Dengan demikian secara umum tampak bahwa ESB lebih

baik jika dibandingankan dengan point-to-point. Dari hasil tersebutEAI yang

diusulkan adalah solusi dengan implementasi enterprise service bus (ESB).

111


Tabel 5.11 Perbandingan mekanisme integrasi

No Kategori Mekanisme Integrasi Rekomendasi

Integrasi Point-to-point ESB

1 SOAP Dibutuhkan format SOAP message yang

diketahui oleh aplikasi lain agar aplikasi tersebut

dapat berkomunikasi. Perbedaan format

menyebabkan perlunya modifikasi pada aplikasi.

Aplikasi dapat menggunakan format

SOAP message yang ada. Jika

terdapat perubahan maka

penyesuaian dilakukan pada ESB

tanpa diperlukan perubahan pada

aplikasi.

ESB

2 REST Dibutuhkan format yang juga diketahui oleh

aplikasi lain agar aplikasi tersebut dapat

berkomunikasi. Perbedaan format menyebabkan

perlunya modifikasi pada aplikasi.

Aplikasi dapat menggunakan format

yang ada. Jika terdapat perbedaan

maka penyesuaian dilakukan pada

ESB agar aplikasi dapat tetap

berkomunikasi. Tidak perlu

perubahan pada aplikasi.

ESB

3 MQ Diperlukan implementasi MQ server tersendiri Terintegrasi dalam ESB ESB

4 FTP Diperlukan implementasi FTP server tersendiri Terintegrasi dalam ESB ESB

112


No Kategori Mekanisme Integrasi Rekomendasi

Integrasi Point-to-point ESB

5 Database adapter Memerlukan kode program tambahanatau

library tambahan agar aplikasi dapat

berkomunikasi dengan database.

Kebanyakan produk ESB telah

mendukung sebagian besar database

yang ada di pasaran.

ESB

6 Kompleksitas

Integrasi

Kompleksitas integrasi tinggi dikarenakan

integrasi bersifat tighly coupled.

Kompleksitas integrasi lebih rendah

dikarenakan integrasi bersifat loosely

coupled.

ESB

7 Fleksibilitas Rendah dikarenakan misalnya dibutuhkan

transformasi data maka perubahan harus

dilakukan pada aplikasi.

Tinggi dikarenakan ESB

menyediakan fungsi transformasi

data sehingga satu sumber data dapat

dipergunakan oleh banyak aplikasi

lain walaupun tiap aplikasi

membutuhkan format yang berbeda.

ESB

8 Efisiensi

komunikasi

Tinggi karena antar aplikasi berhubungan

langsung

Lebih rendah dikarenakan terdapat

penambahan layer aplikasi. Point-to-point

113


5.3.5.6 Unifikasi platform arsitektur

Pada tahap sebelumnya telah didefinisikan bahwa EAI dilakukan dengan

implementasi ESB. Untuk itu platform arsitektur teknologi pada tahap

sebelumnya disesuaikan dengan dilakukan unifikasi platform arsitektur. Unifikasi

pada integrasi dilakukan dengan implementasi ESB. Hal ini disajikan pada

gambar 5.14.

Client Interface

Network

Presentation

Application


Database

Web Browser

Enterprise Service Bus

TPF on Z/OS

SOAP REST FTPMessage Queue

Windows Native Client

Mobile Web Browser

Mobile Native Client

AndroidIOS

Windows Phone

InternetLAN

DatabaseServer

DatabaseServer

DB Conn

Application Server

Java Server .NET Server

DatabaseServer

Windos Application

DatabaseServer

Web Server & PHP

Data warehouse

Gambar 5.14 Unifikasi platform arsitektur teknologi

EAI ini juga sesuai dengan yang telah didefinisikan dalam arsitektur gabungan

dengan memperhatikan prinsip-prinsip arsitektur yang telah didefinisikan.Pada

beberapa kasus terdapat layanan yang digunakan bersama, misalnya layanan yang

diberikan oleh PSS. Layanan PSS tersebut selain digunakan bersama juga dapat

ditransformasi baik data ataupun protokol yang digunakan. Hal tersebut

dimungkinkan dengan diimplementasikannya ESB.

5.3.5.7 Topologi Infrastruktur

Topologi infrastruktur target disajikan pada gambar 5.15. Secara umum tidak

banyak perubahan yang ditargetkan dari sisi topologi infrastruktur. Hal ini karena

Asyst saat ini telah memiliki infrastruktur yang cukup baik didukung dengan hal-

hal sebagai berikut:

114


• Ketersediaan DRC site

Asyst telah memiliki DRC site yang terletak di kota yang berbeda dengan

data center utama. Beberapa aplikasi telah diimplementasikan di DRC site

sehingga jika terjadi bencana dan diputuskan berpindah ke DRC site, maka

hal tersebut dapat dilakukan.

• Penggunaan virtualisasi

Virtualisasi juga telah digunakan dan hal ini sejalan dengan prinsip arsitektur

maximize agility and flexibility of application and Infrastructure. Adanya

virtualisasi juga memungkinkan dilakukannya scaling-up dengan lebih mudah

dikarenakan fleksibilitas yang ditawarkan.

• Penggunaan SAN

Penggunaan SAN juga telah dilakukan dan akan memberikan fleksibilitas

dalam hal scaling dan lain-lain.

• Implementasi keamanan jaringan

Implementasi keamanan jaringan juga telah dilakukan dengan pemasangan

firewall untuk lalu-lintas data yang masuk ke data center.

• Penggunaan load balancer

Load balancer juga telah digunakan sebagai salah satu mekanisme untuk

mendukung clustering sesuai dengan prinsip arsitektur maximize agility and

flexibility of application and Infrastructure. Dengan adanya load balancer

dimungkinkan dukungan infrastruktur sehingga aplikasi dapat di-cluster

sesuai dengan kebutuhan. Selain untuk menunjang agar sistem mempunyai

high availability hal ini juga menunjang agar dapat dilakukan scaling-out

pada sistem.

115


CloudAccess

Public

Medium Switch

Switch


Storage

High EndRouter

MPLS Telkom


Internet

Public UserPublic User

Mainframe


Storage

High EndRouter

DATA CENTER

DRC

Firewall

Load Balancer

Core Switch

Access Switch

Distribution Switch

Server Switch

Distribution Switch

Distribution Switch

Medium Switch

Switch

MediumRouter

Firewall

Mainframe

Core Switch

Distribution Switch

Distribution Switch

Load Balancer

Server Switch

Access Switch

MediumRouter

SITA

MPLS Telkom


Distribution Switch

Airline ClientAirline Client

Gambar 5.15 Topologi infrastruktur

Namun demikian terdapat beberapa hal yang masih perlu ditingkatkan diantaranya

pada DRC site. Hal ini dikarenakan pada DRC site saat ini hanya

mempunyaijaringan yang terhubung ke internet publik dan jaringan SITA dan

belum ada jaringan yang menghubungkan ke jaringan utama Asyst ataupun ke

pihak partner. Untuk itu diusulkan dilakukan dengan penambahan VPN IP MPLS

(multi protocol label switching).

Untuk bidang infrastruktur Asyst memberikan dukungan untuk layanan aplikasi-

aplikasi yang dibutuhkan oleh airline. Hal ini dilakukan dengan model software

116


as a service (SaaS) dengan pemanfaatan cloud. Sejalan dengan hal ini, arsitektur

teknologi pada topologi infrastruktur yang ditargetkan didesain agar mendukung

pemanfaatan cloud. Dengan pemanfaatan cloud maka airline dapat menggunakan

layanan-layanan yang diberikan oleh Asyst dengan langsung mengakses melalui

cloud melalui tipe client interface yang bersesuaian bergantung pada aplikasinya.

Hal ini juga diilustrasikan pada gambar 5.15.

5.3.6 Peluang dan solusi

Tahap peluang dan solusi dilakukan dengan analisis kesenjangan. Analisis

kesenjangan dilakukan untuk sistem informasi dan juga untuk infrastruktur TI.

Analisis kesenjangan dilakukan dengan model TOGAF dengan membentuk

matrix architecture building block (ABB) dari arsitektur baseline dan target.

5.3.6.1 Analisis kesenjangan sistem informasi

Analisis sistem informasi menggambarkan kesenjangan sistem informasi antara

arsitektur baseline dan arsitektur target. Hasil analisis kesenjangan sistem

informasi disajikan pada tabel 5.12.

Secara umum terdapat total 25 sistem informasi dengan rincian 16 sistem yang

sebelumnya telah ada dan 9 sistem informasi baru. Dari 16 sistem informasi yang

sebelumnya telah ada, 5 sistem informasi memerlukan upgrade dan 11 sisanya

dipertahankan.

117


Tabel 5.12 Analisis kesenjangan sistem informasi

Sistem Informasi Target

RMS Planning

& Sche-

duling

Aircraft

Mana-

gement

Netline

Crew

PSS IBE-B2C IBE-B2T Meal

Moni

-

toring

Ops

Control

FOQA E-

Brie-

fing

Sist

em In

form

asi S

aat i

ni

RMS retain

Planning & Scheduling retain

Aircraft Management upgrade

Crew management upgrade

PSS upgrade

IBE-B2C upgrade

IBE-B2T upgrade

Meal Monitoring retain

Ops Control retain

FOQA retain

E-Briefing retain

118


Tabel 5.12 Analisis kesenjangan sistem informasi (sambungan)


AIRCOM Sentinel FFP

(sMile)

CFD FIDS PSS

GUI

OTA-

API IBE-

Mobile

CRM SMS Booking

Sist

em I

nfor

mas

i Sa

at

ini

AIRCOM retain

Sentinel retain

FFP (sMile) retain

CFD retain

FIDS retain

Baru add add add add add

Tabel 5.12 Analisis kesenjangan sistem informasi (sambungan)


Deposit Management Mobile Check-in KIOSK Web Check-in

Sist

em

Info

rmas

i Sa

at

ini

Baru add add add add

119


5.3.6.2 Analisis Kesenjangan infrastruktur TI

Analisis kesenjangan infrastruktur TI membandingkan antara kondisi saat ini

dengan arsitektur target. Tabel 5.13 menyajikan analisis kesenjangan infrastruktur

TI. Secara umum terdapat toal 18 item infrastruktur yang teridentifikasi dengan

16 diantaranya adalah infrastruktur yang telah ada saat ini. Infrastruktur TI yang

merupakan tambahan baru adalah data warehouse dan business intelligence dan

ESB. Dari 16 infrastruktur yang sebelumnya telah ada 2item infrastruktur

memerlukan upgrade, yaitu monitoring dengan Zenoss dan infrastruktur jaringan.

120


Tabel 5.13 Analisis kesenjangan infrastruktur TI


VM

Ware

Zenoss LDAP Enterprise

firewall

SSL Database

Oracle

Database

MySQL Linux

Server Windows

Server

Z/OS

Sist

em In

form

asi S

aat i

ni

VMWare retain

Zenoss upgrade

LDAP retain

Enterprise firewall retain

SSL retain

Database Oracle retain

Database MySQL retain

Linux Server retain

Windows Server retain

Z/OS retain

Mail Server

121


Tabel 5.13 Analisis kesenjangan infrastruktur TI (sambungan)


Mail

Server

Java

Application

Server (JBoss)

PHP web server

(Apache web

server)

Storage

area

network

Infrastruktur

jaringan

Jaringan ke

eksternal

Data

warehouse

dan BI

ESB

Sist

em In

form

asi S

aat i

ni

Mail Server retain

Java Application

Server (JBoss)

retain

PHP web server

(Apache web server)

retain

Storage area network retain

Infrastruktur jaringan upgrade

Jaringan ke eksternal retain

Baru add add

122


5.3.6.3 Evaluasi perencanaan enterprise architecture

Dari EA yang telah dibangun perlu dilihat kesesuainnya dengan kebutuhan bisnis

yang ada dan harapan dari stakeholder. Berikut adalah penjelasan hal tersebut:

• Dapat memenuhi permintaan klien dengan cepat. Hal ini terakomodir dalam

prinsip arsitektur design for change. Dengan ditetapkannya prinsip arsitektur

design for change maka aplikasi terbagi dalam layer-layer berbentuk multi-

tier sehingga perubahan pada satu layer tidak berefek ke dalam layer yang

lain. Hal ini dapat mempercepat dalam memenuhi permintaan klien

dikarenakan jika dibutuhkan kustomisasi terhadap aplikasi maka hal tersebut

dapat dilakukan dengan lebih efisien dengan waktu yang cepat dikarenakan

perubahan hanya dilakukan pada area yang diperlukan.

• Dapat mengakomodasi kebutuhan bisnis yang ada. Hal ini terakomodir dari

penelitian yang dilakukan dengan dihasilkannya EA dengan arsitektur bisnis,

arsitektur sistem informasi, dan arsitektur teknologi. EA yang dihasilkan

berdasarkan pada pola solusi dari permasalahan yang ada termasuk

permasalahan dalam hal produk, yaitu ada kebutuhan bisnis yang belum

dipenuhi. Contoh dari hal ini adalah ditetapkannya solusi SI/TI OTA-API

dan Mobile-IBE dari permasalahan sales distributon harus terhubung ke

banyak channel dan payment.

• Adanya arsitektur aplikasi di level enterprise dengan mengutamakan resource

sharingdan pemanfaatan cloud computing sehingga economies of scale dapat

tercapai. Hal ini terakomodir dalam EA yang dihasilkan dengan penerapan

prinsip arsitektur service orientation. Cloud computing dilakukan dengan

infrastruktur yang dimiliki Asyst dengan implementasi private cloud.

Dengan ditetapkannya prinsip arsitektur service orientation maka aplikasi

yang ada akan didesain dengan menyediakan service/layanan dengan protokol

open standard untuk kemudahan interoperabilitas. Hal ini memberikan

kemudahan dalam hal resource sharing dimana layanan yang ada dapat

digunakan kembali oleh aplikasi lain yang membutuhkan fungsi serupa. Hal

ini misalnya layanan perhitungan fare yang ada pada PSS dapat digunakan

oleh IBE-B2C, IBE-B2T, dan lain-lain.

123


• Arsitektur yang diutamakan adalah pada level PSS dan aplikasi yang terkait

dengannya misalnya IBE dengan penggunaan ESB (enterprise service

bus).Hal ini telah terakomodir dalam desain EA dengan PSS adalah salah satu

aplikasi yang ada dalam arsitektur aplikasi. Aplikasi-aplikasi yang

mempunyai keterkaitan langsung dengan PSS juga telah terakomodir seperti

contohnya adalah IBE-B2C, IBE-B2T, dan lain-lain.

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

ini terakomodir dalam platform arsitektur teknologi. Dalam platform

arsitektur teknologi mekanisme integrasi didesain dengan menggunakan ESB

dilengkapi dengan dasar penggunaan ESB sebagai mekanisme integrasi.

• Memberikan fleksibilitas jika terjadi perubahan pada satu aplikasi yang

terkait dengan aplikasi lainnya. Untuk mengatasi hal ini dalam penyusunan

EA didefinisikan prinsip arsitektur design for change. Dengan prinsip

arsitektur design for change maka aplikasi terbagi dalam layer-layer

berbentuk multi-tier sehingga perubahan pada satu layer tidak berefek ke

dalam layer yang lain. Hal ini misalnya dalam desain EA dihasilkan bahwa

dibuat PSS-GUI sebagai presentation layer bagi PSS. Perubahan hanya perlu

dilakukan pada presentation layer dan tidak pada layer yang lain.

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

bersifat best practice standard. Hal ini diakomodir oleh prinsip arsitektur

maximize agility and flexibility of application and infrastructure, secure

information dan interoperability. Dalam hal meningkatkan robustness

prinsip arsitektur yang berperan adalah maximize agility and flexibility of

application and infrastructuredan secure information. Dalam prinsip

arsitektur maximize agility and flexibility of application and

infrastructureditetapkan bahwa aplikasi dan infrastruktur yang ada dapat

selalu memenuhi tuntutan bisnis. Dapat dilakukan scaling dengan mudah

terhadap Aplikasi dan infrastruktur. Hal ini mengisyaratkan bahwa aplikasi

dan infrastruktur harus dapat memenuhi tuntuan bisnis walaupun terkadang

terdapat kondisi-kondisi yang yang tidak ideal seperti jumlah request dari

layanan yang meningkat. Untuk mencegah kegagalan sistem maka prinsip

arsitektur ini menjamin bahwa dapat dilakukan scaling untuk menangani hal

124


tersebut. Prinsip arsitektur secure information juga berperan dalam hal

robustness aplikasi. Hal ini karena dalam prinsip arsitektur secure

information keamanan data dan aplikasi akan dijaga dan dalam beberapa

kasus kebocoran informasi terjadi karena sistem yang tidak robust dengan

manipulasi input untuk menghasilkan ouputyang tidak sesuai dengan

spesifikasi sistem. Kemudian standar-standar teknologi yang bersifat best

practice standard diakomodir dalam prinsip arsitektur interoperability.

Dalam prinsip arsitektur interoperability didefinisikan bahwa teknologi

bersifat open standard tidak bergantung pada spesifik teknologi tertentu

sehingga antar aplikasi dapat berkomunikasi. Hal ini contohnya adalah

mekanisme integrasi menggunakan web service, baik melalui SOAP atau

REST, penggunaan JMS untuk messaging dan FTP untuk file transfer.

• Memiliki fungsi kontrol dan monitoring yang memadai untuk operasional.

Hal ini menjadi salah satu permasalahan yang telah diidentifikasi pola

solusinya dalam penyusunan EA. Pola solusi dari permasalahan ini adalah

perlunya upgrade pada monitoring.

• Desain arsitektur yang memenuhi standard policy dan complience yang ada

seperti IT security requirement dan lain-lain. IT security requirement

menjadi salah satu prinsip arsitektur dalam penyusunan EA, yaitu prinsip

arsitektur secure information.

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

menggunakan metode lain seperti XML web servicebased. Telah ditetapkan

pola solusi untuk hal ini, yaitu dengan solusi SI/TI upgrade PSS dengan

pengembangan PSS service.Dengan PSS service akses ke PSS dapat

dilakukan melalui web service sehingga pertukaran data dapat melalui format

yang terdefinisi.

• PSS perlu dibuatkan GUI dengan menggunakan XML web service untuk

memberikan daya jual yang lebih baik. Hal ini juga menjadi salah satu

permasalahan yang ditetapkan pola solusinya dengan pola solusi SI/TI

pengembangan PSS GUI. PSS GUI selain menyediakan akses berupa GUI

yang lebih berorientasi kepada mouse click juga dapat menyediakan interface

dengan pola yang ada saat ini yaitu melalui entry pada console.

125


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

terangkum dalam prinsip arsitektur business continuity. Dalam prinsip

arsitektur business continuity didefinisikan bahwa sistem dapat tetap berjalan

walaupun terjadi gangguan. Gangguan dapat berupa kegagalan hardware,

data corruption ataupun bencana alam. Selain itu dari arsitektur teknologi

didapatkan bahwa digunakan teknologi virtualisasi dan penggunaan load

balancer. Dua teknologi tersebut digunakan untuk meningkatkan availability

aplikasi dengan cara clustering agar didapatkan sistem yang bersifat fault

tolerance dan juga memberikan kemudahan untuk dilakukan scaling, baik

scaling-up maupun scaling-out. Dengan demikian aplikasi diharapkan akan

mempunyai high availability 24/7.

EA yang dihasilkan juga telah diverifikasi kembali ke stakeholder dengan

keterangan sebagai berikut:

• Arsitektur bisnis

Arsitektur bisnis yang ada telah mengakomodir proses bisnis yang ada pada

sebuah airline. Proses bisnis inti pada airline meliputi planning and

scheduling, sales, pre-flight, in-flight, dan post-flight. Detail proses untuk

masing-masing proses inti adalah seperti tergambar pada arsitektur bisnis

pada bagian 5.2.3.

• Arsitektur Sistem Informasi – arsitektur data

Arsitektur data yang ada telah dapat mendukung proses bisnis yang ada. Hal

ini erat kaitannya dengan arsitektur aplikasi dimana distribusi data akan

meluas seiring dengan meningkatnya aplikasi dan proses bisnis yang ada.

• Arsitektur sistem informasi – arsistektur aplikasi

Arsitektur sistem informasi yang didefinisikan telah dapat mendukung bisnis

proses yang ada. Beberapa aplikasi mendapat feedback dari stakeholder

diantaranya adalah:

1. SMS-booking. Aplikasi ini akan sangat berguna pada kondisi dimana

konektivitas internet tidak terlalu baik. Pada kondisi ini proses booking

dapat dilakukan melalui SMS-booking untuk mendapatkan seat pada

jadwal penerbangan tertentu. Selanjutnya proses ticketing dapat

dilakukan pada TO misalnya pada TO di bandar udara keberangkatan.

126


Dengan demikian maka calon penumpang telah memperoleh seat pada

saat akan melakukan penerbangan.

2. Aplikasi KIOSK dapat bersifat situasional bergantung pada kondisi dan

lebih efektif pada kondisi dimana bandar udara keberangkatan dekat

dengan keramaian misalnya pusat perbelanjaan. Hal ini dimaksudkan

agar penumpang yang berada pada pusat keramaian dapat melakukan

check-in tanpa harus ke bandar udara keberangkatan.

3. Aplikasi lainnya telah mencukupi dan dapat mendukung bisnis proses

yang ada pada suatu airline.

• Arsitektur teknologi

Arsitektur teknologi juga telah memenuhi untuk mendukung proses bisnis.

Arsitektur dengan pemanfaatan cloud telah memberikan akses yang mudah

bagi airline untuk mengakses sistem. Penggunaan teknologi berbasis web

seperti misalnya pada IBE-B2T memberikan fleksibilitas bagi airline dan

agen perjalanan untuk mengakses aplikasi dimana saja dan kapan saja. Hal

ini penting terutama karena aplikasi dapat diakses melalui mobile device

seperti tablet. Fleksibilitas tersebut memberikan manfaat lebih bagi airline

dikarenakan proses penjualan tiket menjadi tidak terikat ke satu tempat

tertentu dan dapat dilakukan di manapun.


BAB 6

KESIMPULAN DAN SARAN

Bab ini berisikan kesimpulan dan saran dari penelitian yang telah dilakukan.

5.1 Kesimpulan Dari penelitian yang telah dilakukan dapat ditarik beberapa kesimpulan sebagai

berikut:

1. Desain arsitektur yang ada berikut dengan analisis kesenjangan telah dapat

menjawab research question penelitian, yaitu bagaimana enterprise

architecture yang dapat mengakomodir bisnis inti airline yang dapat

dibangun Asyst agar tercapai resource sharing dan integrasi antar aplikasi

yang tercakup EA yang disusun berdasarkan TOGAF ADM.

2. Kondisi yang ditargetkan manajemen diharapkan dapat tercapai dengan

penerapan prinsip-prinsip arsitektur dan desain EA yang dihasilkan (merujuk

ke evaluasi perencanaan enterprise architecture pada poin 5.3.6.3). Hal ini

didukung dengan verifikasi terhadap stakeholder bahwa desain EA yang

dihasilkan telah mengkomodir bisnis inti yang ada pada airline.

3. Pada langkah awal penyusunan EA didefinisikan requirements of architecture

work sebagai kebutuhan penyusunan EA. Requirements of architecture work

menjadi dasar bagi penyusunan prinsip-prinsip arsitektur. Prinsip-prinsip

arsitektur menjadi aturan dan panduan umum dalam pengembangan EA.

4. Iterasi pertama dari TOGAF ADM menghasilkan kondisi enterprise saat ini

sebagai berikut: 1) arsitektur bisnis menghasilkan 15 proses inti; 2) arsitektur

data, diidentifikasi 20 data yang digunakan untuk kebutuhan bisnis; 3)

arsitektur aplikasi, terdapat 16 aplikasi yang teridentifikasi dengan PSS

sebagai aplikasi utama dan digunakan oleh 7 dari 15 proses bisnis inti; dan 4)

arsitektur teknologi, diidentifikasi bahwa saat ini Asyst telah memiliki data

center utama dan data center ke-2 sebagai disaster recovery center.

5. Perencanaan EA dimulai dengan menyusun pola solusi dari permasalahan

yang ada. Pola solusi dibuat dengan memperhatikan prinsip-prinsip arsitektur

yang telah ditetapkan. Dari pola solusi yang ada, pada visi arsitektur

dihasilkan diagram konsep solusi yang memberikan gambaran secara umum

dari arsitektur target dengan perubahan-perubahan yang diperlukan.

128


6. Arsitektur pada iterasi ke-2 arsitektur target: 1) arsitektur data, terdapat 2 data

tambahan untuk mengakomodir solusi permasalahan yang ada; 2) arsitektur

aplikasi, terdapat 9 aplikasi tambahan yang diantaranya terdapat solusi

aplikasi yang menjadi enabler bagi model bisnis airline; 3) Arsitektur

teknologi menghasilkan platform arsitektur teknologi dan gambaran target

topologi infrastruktur.

7. Analisis Kesenjangan terbagi menjadi analisis kesenjangan sistem informasi

dan analisis kesenjangan infrastruktur. Pada analisis kesenjangan sistem

informasi terdapat total 25 sistem informasi dengan rincian 16 sistem yang

sebelumnya telah ada dan 9 sistem informasi baru. Dari 16 sistem informasi

yang sebelumnya telah ada, 5 sistem informasi memerlukan upgrade dan 11

sisanya dipertahankan. Pada analisis kesenjangan infrastruktur terdapat total

18 item infrastruktur yang teridentifikasi dengan 16 diantaranya adalah

infrastruktur yang telah ada saat ini. Infrastruktur TI yang merupakan

tambahan baru adalah data warehouse dan business intelligence dan ESB.

Dari 16 infrastruktur yang sebelumnya telah ada,2 item infrastruktur

memerlukan upgrade, yaitu monitoring dengan Zenoss dan infrastruktur

jaringan.

5.2 Saran

Berdasarkan penelitian yang telah dilakukan dan hasil yang didapatkan terdapat

beberapa saran sebagai berikut:

1. Penyusunan EA yang dilakukan saat ini mungkin masih menyimpan

kekurangan. Hal ini perlu langkah berkelanjutan dengan dapat

mengimplementasikan metode iteratif TOGAF ADM sehingga selalu

didapatkan EA yang optimal.

2. Melanjutkan penelitian yang telah dilakukan dengan langkah-langkah

berikutnya dari TOGAF ADM.

3. Mensinergikan EA yang telah disusun menggunakan TOGAF dengan

framework lain di bidang tata kelola, service management dan lain-lain.

129


DAFTAR PUSTAKA

Laudon, Kenneth C. &Laudon, Jane P. (2012). Management Information

Systems: Managing the Digital Firm (12th ed.), Prentice Hall.

Minoli, Daniel (2008). Enterprise Architecture A to Z, CRC Press.

Lankhorst, Marc et al (2009). Enterprise Architecture at Work: Modelling,

Communication and Analysis Second Edition, Springer.

Scheckkerman (2011). Enterprise Architecture Tool Selection Guide, Institute for

Enterprise Arhitecture Developments.

The Open Group (2013). The open group architecture framework (TOGAF). Mei

2013. The Open Group.http://www.opengroup.org/togaf/.

Chacko, Zenon et al (2010). Middleware Integration Model for Smart Hospital

System Using the Open Group Architecture Framework (TOGAF). 14th

International Conference on Intelligent Engineering Systems. IEEE.

Zhang Yakunet al (2009). On Airlines Sustainable innovation Driven by SOA

Governance. 2009 International Conference on Information Management,

Innovation Management and Industrial Engineering. IEEE.

Juric, Matjaz B. et al (2007). Web Services and Java Middleware Functional and

Performance Analysis for SOA. 2007 Inaugural IEEE International

Conference on Digital Ecosystems and Technologies (IEEE DEST 2007).

IEEE.

Sessions, Roger (2007). A Comparison of the Top Four Enterprise-Architecture

Methodologies. Juni 2013. Microsoft Developer Network.

http://msdn.microsoft.com/en-us/library/bb466232.aspx.

Soomro, Tariq Rahim&Awan, Abrar Hasnain (2012). Challenges and Future of

Enterprise Application Integration. International Journal of Computer

Applications, Vol. 42 No 7.

Ward, John & Peppard, Joe (2011). Strategic Planning for Information Systems

(3rd Ed.), John Wiley & Sons.

uiperpustakaan

Sticky Note

130

LAMPIRAN

Lampiran 1. Wawancara dengan Chief Technical Officer (CTO) Asyst

Keterangan:

P: pewawancara

N: narasumber

Wawancara sesi 1:

P: Sebagai penyedia TI khususnya untuk airline, siapa sajakah klien-klien Asyst

saat ini?

N: Asyst saat ini mempunyai beberapa klien. Salah satunya adalah PT XYZ dan

juga beberapa klien non PT XYZ.

P: Seperti apakah strategi TI yang diambil oleh Asyst?

N: Asyst diharapkan bisa cepat men-deliver aplikasi yang diminta oleh

client.Salah satu strategi yang diterapkan adalah dengan strategic partner. Saat

ini di Asyst capital dan resource (termasuk people) yang ada masih terbatas.

P: Seperti apakah kondisi saat ini yang ada di Asyst?

N: Untuk PT XYZ, core aplikasi reservasi akan menggunakan Amadeus Altea dan

terhubung dengan Tibco ESB dengan aplikasi-aplikasi yang lain yang ada di PT

XYZ. Saat ini di Asyst juga mempunyai core aplikasi reservasi berbasis HP

release 15 ditambah dengan aplikasi-aplikasi yang lain seperti IBE, ERP, Cargo

System dan lain-lain.Saat ini juga Asyst belum mempunyai data warehouse, BI

dan CRM system dan hal tersebut harus direncanakan.

P: Akan seperti apakah rencana kedepannya?

N: Perlu dibuat arsitektur aplikasi dengan ESB. Design yang digunakan akan

seperti apa dan menggunakan platform apa.Akan dibuat sistem yang terpisah dari

infrastruktur XYZ dan akan ada tim yang berbeda dengan yang meng-handle

untuk klien XYZ. Infrastuktur tersebut dapat digunakan oleh klien Asyst saat

ini.Yang ingin dicapai adalah shared resources untuk mencapai ecomonies of

scale dan untuk itu diperlukan desain arsitektur dan bisa menggunakan cloud.

131

Yang perlu diperhatikan juga adalah aspek security, data dan integrity. Dapat

juga dilakukan eksplorasi penggunaan ESB. Kemudian layanan yang diberikan

oleh Asyst harus tersedia 24/7.

Wawancara sesi 2:

P: Bagaimana keadaan arsitektur yang ada di Asyst saat ini untuk mendukung

kebutuhan bisnis?

N: Architecture saat ini bersifat “hair ball” or “point-to-point”connection antar

satu aplikasi dengan aplikasi lainnya. Hal ini kurang memberikan flexibility jika

terjadi perubahan pada satu aplikasi, dimana aplikasi lainnya yang terkait akan

membutuhkan perubahan. Disamping time to market, cost impact juga akan

terkena dampaknya, termasuk juga performance reliability dari system

architecture yang ada saat ini.

Disamping architecture, implementasi dari aplikasi maupun infra/network yang

ada saat ini belum memiliki monitoring functions yang adequate untuk dapat

dipakai dalam system operational sehingga agak menyulitkan dalam

menghandleproblem maupun melakukan enhancement.

P: Jika terdapat permasalahan, apakah bisa dijelaskan lebih lanjut tentang

permasalahan yang ada dari architecture yang ada saat ini?

N: Lebih sulit untuk melakukan troubleshooting karena terlalu banyak point yang

yang harus di-check. Dan dengan sangat minimnya logs atau monitoring tools

yang ada dalam design maupun implementasi dari system aplikasi maupun

infra/network, problem solving menjadi cukup challenging.

Disamping dari sudut pandang architecture, business process untuk menghandle

problem juga masih minim dalam pelaksanaannya. Hal ini menjadi salah satu

element vital untuk mendapatkan service excellence disamping kualitas yang

bagus disisi design dan implementasi dari solusi yang dideploy.

P: Apa saja harapan terhadap enterprise architecture yang akan dibuat?

N: Harapannya adalah bahwa architecture yang dibuat dapat memenuhi beberapa

parameter penting dalam mencapi service excellence kepada customer dari Asyst:

132

o Simple, flexible dan agile enough dalam mensupport business needs.

o Oleh karenanya dapat membantu mencapai kebutuhan time to market yang

lebih cepat, meningkatkan cost efficiency dan dapat meningkatkan

productivity.

o Robust design, dan memakai standard-standard technology yang commonly

used di market (best practice standard)

o Architecture yang dibuat mempertimbangkan aspek operasional sehingga

memudahkan dalam kontrol dan monitoring dari system performance.

o Architecture yang dibuat memenuhi standard policy dan compliance yang

ada, such as IT Security requirement, etc.

P: Pada Kesempatan terdahulu disebutkan bahwa salah satu harapan adalah bahwa

dengan adanya EA maka solusi untuk klien dapat di-deliver dengan lebih cepat

(time to market yang lebih cepat). Bagaimana dengan time to market saat ini?

Berapa lama waktu yang kira-kira dibutuhkan untuk men-deliver solusi bagi

airline terkait dengan bisnis intinya (PSS, IBE B2C, IBE B2T)? Kemudian berapa

lama waktu yang menjadi harapan nantinya?

N: Hal ini jawabannya sangat relatif jika terkait lama waktu yang dibutuhkan,

tergantung besar kecil dari pekerjaan yang akan dilakukan. Mungkin saya jawab

dengan cara yang berbeda. Contoh: Jika terjadi perubahan di PSS (sebagai core

system airline) yang mana perubahan itu akan mempengaruhi IBE, RMS dan

Netline Ops, maka disemua aplikasi tersebut perlu dilakukan perubahan dan

integration test untuk meyakinkan perubahan tersebut dapat berjalan dengan baik

disemua aplikasi tersebut. Sementara jika architecture dilakukan dengan konsep

SOA (for example), maka perubahan cukup dilakukan di sisi PSS (sebagai point

dimana perubahan tersebut terjadi) dan di integration layer (SOA) tersebut,

sehingga perubahan di end point application dapat di-minimize (jika tidak

mungkin untuk di-eliminate). Dari gambaran diatas, dapat disimpulkan waktu

yang diperlukan.

P: Diketahui bahwa saat ini model komunikasi ke PSS adalah menggunakan

screen scrapping yang mengemulasi cara kerja manusia yaitu dengan urutan

133

entry. Apakah hal ini sudah sesuai harapan ataukah ada masalah tertentu terkait

hal ini? Jika ada mohon dapat dielaborasi beserta harapan-harapan yang ada.

N: Metode screen scrapping bagus namun menjadi kurang efisien jika terjadi

perubahan layout ataupun penambahan karakter dari message yang ingin

ditampilkan. Ini juga akan mempengaruhi time to market, efforts dan cost karena

setiap perubahan yang dilakukan diarea tersebut, maka akan memerlukan efforts

tambahan untuk melakukan perubahan. Sementara dengan method lainnya, seperti

XML, webservice based, hal-hal tersebut tidak diperlukan, disamping kedua

technology ini dapat memberikan lebih banyak functions dan features yang

diperlukan oleh business.

P: Diketahui juga bahwa saat ini model interkoneksi antar aplikasi adalah bersifat

point-to-point. Apakah dapat dielaborasi lebih lanjut permasalahan yang ada

terkait dengan hal ini beserta hal-hal yang diharapkan?

N: Sesuai item diatas.

P: Terkait dengan aplikasi yang berhubungan dengan bisnis inti dari airline yaitu

PSS dan IBE B2C dan B2T, apakah ada masalah khusus tertentu di aplikasi-

aplikasi tersebut saat ini? Kemudian bagaimana harapan dari manajemen terhadap

aplikasi-aplikasi ini?

N: Untuk PSS, secara fungsi dan features sudah bagus, perlu di-explore beberapa

area yang saat ini belum di-utilize. Yang perlu ditingkatkan adalah

dikembangkannya GUI dengan memakai XML, webservice sehingga mampu

memberikan daya jual yang lebih baik. Saat ini agak sulit jika masih memakai

“black screen”, hal ini menjadi kurang efficient dan cukup costly dilapangannya,

i.e., memerlukan constant training jika turn over employee cukup tinggi. Untuk

IBE, B2C, B2B, bisa memakai caseAAA (salah satu contoh klien) dan hal-hal

yang mau kita ubah sesuai diskusi terakhir-terakhir dengan team mainframe.

P: Apa saja yang menjadi hambatan atau tantangan lain dari sisi enterprise

architecture untuk mencapai tujuan bisnis yang ada?

N: untuk dapat mencapai enterprise architecture yang diinginkan (ideal),

memerlukan full support dari manajemen dan memerlukan team dengan technical

134

dan business process capabilities yang memadai. Manajemen harus meyakinkan

bahwa strategi yang akan dicapai clear, consistently di-execute, mampu me-

leveragecomponent yang ada saat ini untuk dijual ke customer-customer baru

lainnya untuk meng-optimizeinvestment. Knowledge di business process dan

technical capabilities sangat key untuk bisa melakukan pengembangan tersebut.

Jika tidak bisa dikembangkan sendiri, partnership dengan 3rd party adalah sangat

memungkinkan.

135

Lampiran 2. Wawancara dengan Head of IT di Salah Satu Klien

Keterangan:

P: pewawancara

N: narasumber

P: Proses bisnis apa saja yang ada di airline?

N: Urutan Process:

1. Unit product dan marketing: bertanggungjawab menyediakan produk,

melakukan market research, mempersiapkan pengadaan aircraft

bekerjasama dengan unit finance tentang permodalan, membuat rotasi

diagram tentang aircraft tersebut, termasuk merancang rute, setup fare,

merancang distribusi channel, promotion, analisis market dan market

share.

2. Unit sales: bertanggung jawab menjual/mengisi pesawat sampai penuh,

melakukan penjualan tiket, sales control, yield control, competitor control,

target sales masing-masing cabang (channel) dan mengontrol total sales,

membuat sales report.

3. Unit technical: bertanggungjawab agar pesawat tidak mengalami problem,

mempersiapkan pesawat (aircraft) agar siap digunakan, maintenance,

spare part.

4. Unit operation: bertanggungjawab agar pesawat terbang on time,

melakukan operation penerbangan (departure flight), schedule crew, flight

log.

5. Unit revenue accounting: bertanggungjawab agar pendapatan dapat

diketahui dengan cepat, tepat dan akurat, kemudian melakukan

penghitungan revenue berdasarkan tiket-tiket yang diterbangkan

(operation).

6. Unit cost accounting: bertanggungjawab menghitung cost, cost control,

menghitung semua cost yang timbul atas penerbangan.

P: Unit-unit bisnis apa saja di airline yang terkait dengan proses-proses yang

ada?

136

N : Lihat 6 poin diatas, secara umum hampir sama dengan airline pada umumnya,

kalaupun ada sedikit masih berbeda itu murni karena waktu itu masih kecil,

namun sekarang sudah berangsur-angsur berkembang menjadi membesar

sehingga akanmenyesuaikan diri dengan airline yang sudah besar.

P:Mohon dideskripsikan kendala-kendala dari tiap unit yang ada terkait dengan

proses yang dilakukan?

N: Kendala yang ada adalah sebagai berikut:

1. Kendala sangat sering terjadi data discrepancy antara data Compass dengan

B2T, data discrepancy itu lebih buruk dari data error, bahkan lebih buruk dari

system down.

2. Kendala Asyst kurang mampu melakukan modifikasi, development,

pengembangan sistem Compass sesuai dengan requirement user.

3. Tidak ada system yield management system, sehingga departement sales,

marketing kesulitan menentukan patokan harga sesuai dengan segmen pasar

dan timing yang menjadi target, disamping itu tidak tersedianya data statistik

pejualan yang dapat dianalisis guna melakukan pengembangan pasar.

4. Tidak adanya API untuk mempermudah berhubungan dengan sistem lain

(vendor) sebagai partner untuk sales, distribusi produk.

P:Bagaimana harapan-harapan kedepannya terkait dengan solusi TI dan dukungan

dari Asyst?

N: Harapan:

1. Asyst dapat men-support secara standar sebagaimana system provider yang

lainnya, ada research dan development. Bisa berkembang sesuai dengan

market domestik maupun international khususnya di bidang airline

2. User conference untuk mendengar keluhan, masukan, input serta Asyst dapat

menyampaikan plan,road map kedepan.

3. Management commitment

137

Lampiran 3. Wawancara dengan Asyst account management untuk airline.

Keterangan:

P: pewawancara

N: narasumber

Wawancara sesi 1:

P: Apakah bisa dijelaskan proses-proses yang ada di sebuah airline?

Proses-proses yang ada pada airline adalah sebagai berikut:

• Proses booking/reservation

• Proses ticketing

• Proses check in

• Additional service :

o Booking seat

o Special meal

o Wheel chairdan lain-lain.

• Proses pre-fligth: dapat melakukan reservasi melalui perwakilan TO

(ticketing office)/APT (airport), web site, travel agent. Untuk di lapangan,

persiapan flight,dokumen inflight, crew schedule, loadsheet, manifest pax,

manifest cargo dan baggage, fuel consumption, report technical support,

weather briefing dan lain-lain.

• Proses in-flight : dapat menikmati layanan di dalam pesawat media

elektronik dan cetak dan layanan masing-masing airline.

• Proses post flight: pelayanan baggage, transit others airlines dan lain-lain.

• Proses revenue accounting: dapat melakukan pelaporan secara real time

yang meliputi plan, reporting data sales dan revenue saat itu dan

mengontrol distribution chanel.

• Proses data management: penyediaan server dan penyimpanan seluruhdata

• Infrastructure dan security : disaster recovery.

138

P: Bagaimana pemanfaatan teknologi informasi (TI) untuk mendukung hal-hal

tersebut?

N: Pemanfaatan teknologi Informasi (TI): melakukan proses pembukuan sampai

dengan pembayaran melalui media internet dan mobile application yang

terintegrasi. Pembayaran melalui fasilitas payment gateway atau payment solution

(DOKU, RINTIS, JATIS, Mitracomm etc).

P: Bagaimana strategi marketing Asyst saat ini khususnya untuk bidang airline?

N: Melakukan pendekatan dengan customer melalui sarana promosi web dan

kunjungan serta memberikan informasi dan kelebihan dari produk yang Asyst

miliki. Pengembangan kedepan bisnis dengan API karena dapat dilakukan oleh

banyak pihak (contoh : Booking.com, Agoda, Traveloka, Jalanjalan dan lain-

lain).

P: Masalah-masalah apa saja yang biasanya ditemui di airline?

N: Yang ada di Asyst problem payment dan deposit yang tidak sesuai dengan

permintaan airline.

P: Bagaimana solusi Asyst bisa membantu mengatasi permasalahan yang ada?

N: Melakukan cek ke semua applikasi

P: Apakah dengan solusi yang diberikan Asyst, masih ditemui masalah pada

airline yang merupakan klien dari Asyst? (mohon dapat dijelaskan permasalahan

yang ada)

N: Selama produk itu diterima pasar dan tidak ada keluhan berarti produk tersebut

sudah sesuai dengan permintaan pasar/customer. Untuk target awal strategi

bisnis adalah membuat produk unggulan yang dapat cepat diterima pasar seperti

penerapan API untuk sarana penjualan airline, Untuk respon dan penanganan

keluhan yang cepat diatasi akan merupakan poin yang tersendiri bagi customer

(airline).

P: Apakah solusi saat ini sudah sesuai harapan? Jika belum seperti apakah

harapannya?

139

N: Belum, perlu perbaikan dan pengembangan ke depan. Pengembangan semua

ada di plan divisi produk.

Wawancara sesi 2:

P: Apakah bisa dijelaskan organisasi dari airline beserta peran dan tanggung

jawabnya?

N: Awalnya adalah BOD sebagai pengambil keputusan kemudian terdapat divisi

marketing ( dapat juga sebagai pecahan dari commercial dan sales). Peran dan

tanggung jawabnya adalah set database, inventory, refund, fare, DCS. Hal ini

juga merangkum bagian revenue management dan dapat juga digabung menjadi

service (in flight service). Peran yang lain adalah sales, menjual produk melalui

distribution channel. Kemudian terdapat divisi flight operation yang menangani

proses di lapangan dan bersifat teknis di pesawat. Hal ini misalnya persiapan

untuk keberangkatan pesawat, persiapan data loadsheet dan cabin crew.

Memproses data network scheduling dan lain-lain. Kemudian terdapat unit

finance dan yang lainnya adalah divisi maintenance yang bertanggungjawab

terhadap maintenace pesawat. Maintenance pesawat dapat dikelola sendiri jika

airline masih kecil namun jika sudah besar biasanya bekerjasama dengan pihak

lain. Bisnis proses meliputi pencatatan tiap elemen dalam pesawat

P: Apa bisa diterangkan lebih lanjut tentang permasalahan-permasalahan yang

ada?

N: Permasalahan yang ada meliputi service offering, misalnya tarif pesawat yang

berbeda antar agen, dimana ada agen yang diberi diskon lebih sehingga ada agen

yang merasa dirugikan. Permasalahan lain contohnya koneksi jaringan di daerah

yang kurang baik sehingga menghambat sistem. Kemudian hal lain yang juga

diperlukan adalah sales distributon harus terhubung ke banyak channel dan

payment. Kemudian juga perlunya KIOSK untuk check-in dan ticketing di airport

dan terhubung ke payment.

140

Lampiran 4. Wawancara dengan manajer flight operationAsyst

P: pewawancaraa

N: narasumber

P: Bagaiman proses bisnis yang ada pada flight operation?

N: Terdapat 5 bagian utama yang terkait dengan flight operation, yaitu:

1. Network planning

2. Aircraft management

3. Crew management

4. Crew link

5. Netline base

Pada network planning proses awal adalah mengeluarkan jadwal seasonal/per

musim setahun 2 kali dikirimkan dari unit JKTCNR ke JKTOGR (JKTCNR dan

JKTOGR adalah nama unit pada airline XYZ yang melakukan pengolelolaan

jadwal. JKTOGR akan mengelola jadwal untuk 60 hari kedepan. Hal ini

misalnya jika ada perubahan ad-hoc, pesawat yang berubah jadwal karena ada

kerusakan atau cuaca buruk. Proses lanjutan akan ditangani oleh JKTOGM (juga

adalah salah satu unit di airline XYZ) yang akan menangani jadwal untuk 3 hari

kedepan. Proses pada network planning menggunakan Netline Sched. Netline

Sched akan mengeluarkan file jadwal seasonal dengan nama SSIM (standar

schedule information message) yang merupakan standar IATA dan file ini akan

dikirim untuk keperluan aircraft management.

Aircraft management akan mengatur jadwal seasonal untuk aircraft. Disini juga

dilakukan registrasi jika ada pesawat baru. Jika terjadi perubahan jadwal maka

akan dikeluarkan data berupa ASM/SSM (adhoc schedule message/standard

schedule message). Dalam ASM/SSM perubahan-perubahan yang ada dapat

mencakup perubahan aircraft, rute, waktu (misalkan ada event tertentu seperti

demo buruh sehingga jadwal penerbangan harus dirubah). Proses Aircraft

management dapat dilakukan melalui aplikasi Netline Ops.

Kemudian crew management akan mengatur penugasan crew untuk setiap

pairing route. Contoh dari pairing route misalnya CGK-JOG-CGK maka crew

141

management akan melakukan penugasan terhadap crew. Crew management juga

akan melakukan tracking dan monitoring dan juga dapat melakukan jadwal untuk

stand-by crew jika nantinya crew yang ditugaskan berhalangan. Untuk melakukan

crew management digunakan aplikasi Netline Crew. Netline crew sendiri akan

melakukan cek secara periodik untuk melihat perubahan aircraft. Hal ini untuk

mencegah agar jangan sampai ada ketidaksesuaian jadwal crew dengan aircraft.

Kemudian selain hal-hal di atas terdapat juga crew link dan Netline Base. Crew

link adalah sebuah portal berbasis web yang dapat digunakan oleh crew untuk

melihat jadwal dan berbagai info untuk 1 bulan ke depan. Kemudian Netline Base

adalah kumpulan data dari aplikasi-aplikasi yang berhubungan dengan flight

operation. Netline base adalah sebuah database management dan berisikan

sharing data antara Netline Sched, Ops, Crew. Misal jika Netline Ops

memasukkan data pesawat baru maka akan dimasukkan ke Netline Base dan

digunakan oleh group aplikasi Netline.

Komunikasi dari aplikasi-aplikasi flight operation ke PSS dilakukan dengan

menggunakan messaging menggunakan MQ Series.

P: Apa saja permasalahan-permasalahan yang ada di flight operation?

N: Salah satu permasalahan yang ada yaitu perhitungan waktu penerbangan (flight

time). Aplikasi yang ada saat ini menghitung dimulai dari saat menyalakan mesin.

Dari user mengharapkan perhitungan dimulai pada saat pesawat berjalan.

Permasalahan lain yaitu tentang optimizer pada Netline Crew. Netline crew

memiliki optimizer (penjadwalan crew otomatis, pairing dan assignment) hanya

saja optimizeryang ada saat ini tidak berjalan karena adanya perbedaan bisnis

proses dengan user, tidak semua crew ter-assign dan ada rule yang tidak

terakomodasi.

Permasalahan lainnya ada pada Netline Ops yaitu pada rotation optimizer.

Rotation optimizer bertujuan untuk optimasi agaraircraft agar selalu ter-utilize.

Misalkan pesawat mendarat, maka tidak terlalu lama berada di ground karena

tidak menghasilkan revenue jika terlalu lama idle. Saat ini sudah ada optimizer

tetapi tidak sesuai.

P: Apa lagi bisnis proses yang berhubungan dengan flight operation?

142

N: Beberapa bisnis proses dan aplikasi yang berhubungan dengan flight operation


• E-Briefing: aplikasi yang berisikan prosedur, keamanan, aturan

penampilan untuk crew. Aplikasi ini terkoneksi ke database IOCS ke

NetlineCrew.

• AIRCOM (aplikasi yang dibuat oleh SITA): air ground communication,

yaitu komunikasi pesawat dan station. Permasalahan yang ada pada

AIRCOM ini adalah komunikasi AIRCOM melalui suatu gateway yang

dinamakan Emedia. Gateway Emedia terkadang komunikasinya tidak

stabil.

• Ops Control: flight planning dan operation control, melakukan feeding

data dari Netline Ops, kemudian dari data rotasi pesawat diolah menjadi

flight plan, termasuk fuel, cuaca (data cuaca diambil dari server milik

Jeppesen). Dari data rotasi didapat tanggal penerbangan dan digabungkan

dengan data cuaca maka dihasilkan rute penerbangan, termasuk juga data

PIC (pilot in charge), bahan bakar, dan koordinat. Permasalahan yang ada

pada hal ini adalah ada kalanyatidak bisa mencetak flight plan. Hal ini

terjadi karena load network yang tinggi sehingga hasilnya

pencetakanberupaprinttelextidak bisa dilakukan.

• Sentinel: mencatat kejadian-kejadian penerbangan diluar prediksi, misal

pintu darurat tak terbuka, safety belt macet, satu mesin mati dan lain-lain.

Sentinel mengeluarkan laporan dan nantinya akan diputuskan action

selanjutnya supaya hal tersebut tidak terjadi lagi. Keputusan akan

dilakukan oleh personel berdasarkandata yang ada pada Sentinel. Hal ini

lebih untuk risk management dengan user aplikasi adalah dari internal

audit.

• FOQA -> flight operationand quality assurance. Digunakan untuk

membaca blackbox. Jika pesawat mendarat maka data blackbox akan

diekstrak. FOQA akan men-decrypt data di blackbox untuk dibaca. Dari

data yang ada dapat dibuat simulasi dari take off sampai landing. FOQA

bisa membaca tergantung data pesawat yang ada. FOQA digunakan untuk

internal audit.

143

Lampiran 5. Wawancara dengan Asyst product management - IBE

P: pewawancara

N: narasumber

P: Bagaimana solusi Asyst untuk mendukung distribution channel seperti IBE?

N: Untuk agen perjalanan adalah dengan B2T (business to travel). Namun saat ini

belum memenuhi kebutuhan seperti misalnya belum connect ke payment gateway

untuk kebutuhan online top-up, dan pembayaran.

Untuk yang berhubungan dengan customer adalah dengan B2C, namun features

harus dilengkapi lagi:

• kebanyakan orang menggunakan mobile access, untuk mobile saat ini yang

tersedia hanya versi menggunakan browser (mobile web), belum ada

native di mobile.

• kebutuhan utama ada di web check-in atau mobile check-in dan juga city

check-in.

P: Apakah solusi yang ada sudah cukup mendukung bisnis proses yang ada di

airline?

N: Tergantung besarnya airline, untuk kelas menengah sudah lebih dari cukup

namun untuk skala lebih besar bisa jadi belum menjawab seluruh kebutuhan

mereka.

P: Seperti apakah trend yang ada di airline saat ini?

N: Intelligent content aggregator/Intermediaries/OTA (online travel agent) yang

menyediakan fasilitas searching dan booking(jadwal penerbangan), hotel, sewa

mobil, dan lain-lain. VCH (value creation hub), kerjasama dengan pihak lain

(misalnya intermediaries) yang dapat memberikan nilai. Mobile check-in, web

check-in, city check-in.

P: Apa saja permasalahan yang ada terkait dengan solusi Asyst?

N: Adanya penerapan yang tidak sesuai dengan industry best practice sehingga

membutuhkan effort/resources besar, contohnya pada B2T deposit management.

144

P: Apa saja kebutuhan-kebutuhan yang ada di airline yang belum di-support oleh

Asyst?

N: web/mobile/city check-in, pay for purchase item, pemesanan hotel dan

kendaraan terintegrasi dari B2C atau B2T, payment gateway.

145

Lampiran 6. Hasil observasi aplikasi dan infrastruktur yang ada di Asyst

No Obervasi Keterangan/Hasil Observasi

1 Enterprise Architecture Belum ada dan belum didefinisikan

secara jelas pada level enterprise

tentang keterkaitan bisnis, sistem

informasi dan teknologi. Yang sudah

ada saat ini adalah keterangan untuk

masing-masing aplikasi dan dituangkan

dalam service catalog

2 Interkoneksi antar aplikasi • Beberapa aplikasi sudah melakukan

interkoneksi terutama dengan PSS

akan tetapi belum didefinisikan pada

level enterprise dan masih bersifat

silo.

• Pada beberapa aplikasi middleware

sudah digunakan secara bersama

oleh beberapa aplikasi. Akan tetapi

dalam hal ini masih ada duplikasi

karena beberapa middleware

melakukan fungsi yang sama di-

deploy pada mesin yang berbeda

untuk melayani aplikasi yang

berbeda.

• Interkoneksi antar aplikasi juga

masih bersifat point-to-point.

3 Aplikasi dan Infrastruktur • Teknologi virtualization

menggunakan vmWare sudah

digunakan.

• PSSyang digunakan Asyst adalah

HP Rel. 15 dengan berbasis pada

mesin mainframe IBM z10.

• Database server untuk aplikasi yang

146

ada saat ini terbagi dua, yaitu:

MySQL yang di-deploy pada satu

mesin dengan satu mesin lain

bertindak sebagai backup. Dalam

hal ini server MySQL akan

melayani seluruh aplikasi yang

membutuhkan database MySQL

Oracle DB juga digunakan pada

beberapa aplikasi seperti FFP.

147

Lampiran 7. Gambaran Umum Service Catalog Asyst

UNIVERSITAS INDONESIA PERANCANGAN ENTERPRISE...

Documents

Transcript of UNIVERSITAS INDONESIA PERANCANGAN ENTERPRISE...