Post on 22-Nov-2020
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
• 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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
• 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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
• 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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
• 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
Universitas Indonesia
• 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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
metodologi yang digunakan adalah berbasiskan TOGAF ADM dengan langkah-
langkah yang telah diilustrasikan pada gambar 2.2dan telah dijelaskan pada bagian
tinjauan pustaka tentang TOGAF. Adapun secara singkat langkah-langkahnya
adalah sebagai berikut:
• Membangun visi arsitektur
• Membangun arsitektur bisnis
• Membangun arsitektur sistem informasi
• Membangun arsitektur teknologi
• Mengindentifikasi peluang dan solusi
• Membuat migration planning
• Mengimplementasikan tata kelola
• Mengimplementasikan arsitektur change management
2.8 Theoretical Framework
Theoretical framework yang dibangun pada penelitian ini adalah berdasarkan
TOGAF ADM. Telah disebutkan pada bagianbatasan penelitian bahwa hasil dari
penelitian ini adalah berupa desain EA yang terangkum dalam target EA.
Penelitian mencakup langkah pendahuluan dengan melibatkan requirements of
architecture work dan prinsip-prinsip arsitektur. Kemudian diikuti dengan
langkah-langkah TOGAF ADM (gambar 2.7).
Pendekatan SOA diterapkan pada tahapan desain arsitektur. Hal ini akan
mempengaruhi desain arsitektur baik dari sisi sistem informasi maupun dari sisi
teknologi dan infrastruktur yang digunakan. Desain SOA yang dibuat akan
dipengaruhi oleh layanan-layanan yang ada pada aplikasi (application services).
32
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
7. Topologi infrastruktur
Topologi infrastruktur akan membahas topologi dari infrastruktur yang
digunakan untuk mendukung aplikasi.
3.11 Peluang dan solusi
Dalam tahap ini akan dilakukan analisis kesenjangan secara menyeluruh dimulai
dari tahap arsitektur bisnis sampai dengan tahap arsitektur teknologi. Dari analisis
kesenjangan akan didapatkan kebutuhan-kebutuhan untuk mencapai arsitektur
yang diusulkan dibandingkan dengan kondisi saat ini.
3.12 Kesimpulan dan saran
Kesimpulan yang didapat adalah evaluasi dari EA yang telah dihasilkan.
Kesimpulan juga mencakup evaluasi dari analisis kesenjangan dari keadaan
sebelumnya dibandingkan dengan kebutuhan untuk implementasi EA yang
dihasilkan dari penelitian.
Saran akan meliputi beberapa aspek yaitu dari sisi pengembangan EA untuk
batasan yang lebih luas, kemudian proses lanjutan dari EA yang dihasilkan seperti
studi penerimaan EA di organisasi dan proses tata kelola TI dalam rangka
penerapan EA.
39 Universitas Indonesia
BAB 4
PROFIL ORGANISASI
Bab ini menjelaskan tentang profil organisasi tempat studi kasus dilakukan. Profil
organisasi akan mencakup tentang sejarah singkat organisasi dilanjutkan dengan
visi dan misi organisasi. Selanjutnya akan dipaparkan tentang produk dan layanan
yang ada di organisasi yang ditujukan untuk pihak eskternal (klien).
4.1 Profil Asyst
PT Aero Systems Indonesia (Asyst) didirikan pada tahun 2005. Asyst telah
mengalami pergantian nama dan sebelumnya bernama PT Lufthansa Systems
Indonesia. Pada awalnya Asyst adalah perusahaan joint venture antara salah satu
maskapai penerbangan di Indonesia (PT XYZ) dengan pihak asing yang bergerak
di bidang penyedia layanan TI untuk airline. Komposisi saham awal adalah 51%
dimiliki oleh PT XYZ dan sisanya dimiliki oleh pemodal asing. Pada tahun 2009
terjadi perpindahan kepemilikan dan saham yang dimiliki oleh pemodal asing
ditransfer ke salah satu anak perusahaan PT XYZ sehingga Asyst resmi tergabung
ke dalam grup XYZ.
4.2 Visi dan Misi
Asyst mempunyai visi untuk menjadi nomor satu sebagai penyedia layanan TI
untuk industri transportasi dengan solusi TI yang komprehensif, terkemuka, dan
lengkap. Sedangkan misi dari Asyst adalah: 1) Membawa nilai tambah bagi PT
XYZ dan XYZ group; 2) Menyediakan layanan TI yang berkualitas dan efisien
dan, 3) Menyediakan solusi TI dengan portofolio yang lengkap. Asyst juga
mempunyai corporate culture yang disebut dengan Get IT On yang dapat
dijabarkan sebagai berikut:
• Integrity: bertindak dengan cara yang 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
Universitas Indonesia
• 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
Universitas Indonesia
• 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
Universitas Indonesia
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
Universitas Indonesia
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.
44 Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
• 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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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.
Proses Bisnis Pendukung
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
Revenue Management System
Crew Management System
E-Briefing
PSS
PSS
PSS
PSS
PSSIBE-B2C
IBE-B2T
Network Planning & Schedulling System
FFP
Meal Monitoring
IBE-B2C
IBE-B2T
Revenue Accounting System
PSS
Maintenace & Engineering Management
Flight Connections
PSS
Proses Bisnis Inti
Aircraft management
Aircraft Management System
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
Universitas Indonesia
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.
Unit terkait: Airline - Operation
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.
Unit terkait: Airline - Operation
5. PSS
Fungsionalitas:
66
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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.
Unit terkait:Airline – Commercial and Business
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.
Unit terkait:Airline – Commercial and Business
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.
Unit terkait: Airline - Operation
11. E-Briefing
Fungsionalitas:aplikasi yang berisikan prosedur, keamanan, aturan
71
Universitas Indonesia
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
Unit terkait: Airline - Operation
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.
Unit terkait: Airline - 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
Universitas Indonesia
No Keterangan
Unit terkait: Airline - Operation
16. FIDS (flight information display system)
Fungsionalitas:
Disebut juga dengan flight monitoring, adalah sebuah solusi untuk
memonitor keberangkatan dan kedatangan untuk industri airline.
Unit terkait:Airline – Commercial and Business
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
Universitas Indonesia
Hosting Place/Virtual Machines
Storage
High EndRouter
SITA
MPLS Telkom
Other TrustedNetwork
Internet
Public User
Public User
Mainframe
Hosting Place/Virtual Machines
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
Universitas Indonesia
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
Universitas Indonesia
No Permasalahan Keterangan
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
Universitas Indonesia
No Permasalahan Keterangan
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
Universitas Indonesia
No Permasalahan Keterangan
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
Universitas Indonesia
No Permasalahan Keterangan
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
Universitas Indonesia
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
Universitas Indonesia
N
o
Permasalahan Sasaran Solusi Pola Solusi Solusi SI/TI
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
Universitas Indonesia
N
o
Permasalahan Sasaran Solusi Pola Solusi Solusi SI/TI
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
Universitas Indonesia
N
o
Permasalahan Sasaran Solusi Pola Solusi Solusi SI/TI
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
Universitas Indonesia
N
o
Permasalahan Sasaran Solusi Pola Solusi Solusi SI/TI
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
Universitas Indonesia
N
o
Permasalahan Sasaran Solusi Pola Solusi Solusi SI/TI
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
Universitas Indonesia
N
o
Permasalahan Sasaran Solusi Pola Solusi Solusi SI/TI
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
Universitas Indonesia
N
o
Permasalahan Sasaran Solusi Pola Solusi Solusi SI/TI
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
• Design for change
• Maximize agility and
flexibility of application
and Infrastructure
• Secure Information
• Penggunaan kembali
• Business Continuity
• Corporate data model
• Kemudahan penggunaan
• Common use application
4 Desain infrastruktur berbasis SOA • Design for change
• Maximize agility and
87
Universitas Indonesia
No Pola Solusi Prinsip Arsitektur
flexibility of application
and Infrastructure
• Service Orientation
• Penggunaan kembali
• Interoperability
5 Desain aplikasi berbasis SOA dengan
pengunaan layanan bersama
• Design for change
• Maximize agility and
flexibility of application
and Infrastructure
• Secure Information
• Service Orientation
• Penggunaan kembali
• Business Continuity
• Corporate data model
• Interoperability
6 Interkoneksi melalui middleware • Design for change
• Maximize agility and
flexibility of application
and Infrastructure
• Secure Information
• Service Orientation
• Penggunaan kembali
• Business Continuity
• Corporate data model
• Interoperability
7 Desain aplikasi berbasis SOA • Design for change
• Maximize agility and
flexibility of application
and Infrastructure
• Secure Information
88
Universitas Indonesia
No Pola Solusi Prinsip Arsitektur
• Service Orientation
• Penggunaan kembali
• Business Continuity
• Corporate data model
• Interoperability
8 Desain implementasi data warehouse • Secure Information
• Business Continuity
• Corporate data model
9 Desain implementasi sistem business
intelligence
• Secure Information
• Business Continuity
10 Desain implementasi sistem CRM • Secure Information
• Business Continuity
• Kemudahan penggunaan
• Interoperability
11 Pengembangan mobile application untuk
IBE dan check-in
• Accessibility
• Design for change
• Maximize agility and
flexibility of application
and Infrastructure
• Secure Information
• Penggunaan kembali
• Business Continuity
• User management
• Corporate data model
• Kemudahan penggunaan
• Common use application
• Interoperability
12 Check-in melalui web secara online,
melalui mobile device dan melalui sistem
check-in mandiri di airport
• Accessibility
• Design for change
• Maximize agility and
89
Universitas Indonesia
No Pola Solusi Prinsip Arsitektur
flexibility of application
and Infrastructure
• Secure Information
• Penggunaan kembali
• Business Continuity
• User management
• Corporate data model
• Kemudahan penggunaan
• Common use application
• Interoperability
13 Pengembangan fungsi pay for purchase
item pada IBE-B2C
• Secure Information
• Penggunaan kembali
• Corporate data model
• Kemudahan penggunaan
• Common use application
14 Pemisahan modul deposit management
agar bersifat modular dengan
pengembangan konfigurasi rule yang
fleksibel
• Design for change
• Secure Information
• Service Orientation
• Penggunaan kembali
• User management
• Corporate data model
• Kemudahan penggunaan
• Common use application
• Interoperability
15 Pengembangan API berupa web service
yang dapat diakses secara lokal dan
public melalui internet
• Design for change
• Maximize agility and
flexibility of application
and Infrastructure
• Secure Information
• Service Orientation
90
Universitas Indonesia
No Pola Solusi Prinsip Arsitektur
• Penggunaan kembali
• Business Continuity
• Corporate data model
• Interoperability
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
• Design for change
• Service Orientation
• Corporate Data model
• Interoperability
17 Layanan di PSS yang dapat digunakan
untuk mendapatkan manifest untuk tiap
jadwal penerbangan
• Secure Information
• Service Orientation
• Corporate Data model
• Interoperability
18 Penyederhanaan model konektivitas • Maximize agility and
flexibility of application
and Infrastructure
• Interoperability
19 Implementasi aplikasi aplikasi yield
management system
• Design for change
• Maximize agility and
flexibility of application
and Infrastructure
• Secure Information
• Service Orientation
• Penggunaan kembali
• Business Continuity
• User management
• Corporate data model
• Kemudahan penggunaan
• Common use application
• Interoperability
91
Universitas Indonesia
No Pola Solusi Prinsip Arsitektur
20 Menyimpan data operasional untuk
kebutuhan analisis dan dari data tersebut
dapat dibentuk statistik dengan grafik
yang sesuai
• Accessibility
• Secure Information
• Penggunaan kembali
• Corporate data model
• Kemudahan penggunaan
21 Pengembangan modul auto agent
registration pada B2T dan service yang
bersesuaian pada PSS
• Design for change
• Secure Information
• Service Orientation
• User management
• Corporate Data model
• Kemudahan penggunaan
• Interoperability
22 Pengembangan PSS Service berupa web
service dengan pre-defined input
• Design for change
• Service Orientation
• Corporate Data model
• Interoperability
23 Pengembangan PSS Service berupa web
service untuk mengurangi jumlah
komunikasi ke PSS
• Design for change
• Maximize agility and
flexibility of application
and Infrastructure
• Secure Information
• Service Orientation
• Penggunaan kembali
• Business Continuity
• Corporate Data model
• Interoperability
24 Pengembangan modul auto agent
registration pada B2T dan service yang
bersesuaian pada PSS
• Design for change
• Secure Information
• Service Orientation
• User management
92
Universitas Indonesia
No Pola Solusi Prinsip Arsitektur
• Corporate Data model
• Kemudahan penggunaan
• Interoperability
25 Pengembangan PSS Service berupa web
service untuk mengurangi jumlah
komunikasi ke PSS
• Design for change
• Maximize agility and
flexibility of application
and Infrastructure
• Secure Information
• Service Orientation
• Penggunaan kembali
• Business Continuity
• Corporate Data model
• Interoperability
26 • Perbaikan koneksi jaringan dan
efisiensi sistem B2T agar mentransfer
data lebih sedikit
• Pengembangan sistem dengan
komunikasi data yang efisien
• Design for change
• Maximize agility and
flexibility of application
and Infrastructure
• Secure Information
• Service Orientation
• Penggunaan kembali
• Business Continuity
• Corporate Data model
• Interoperability
27 Implementasi beragam distribution
channel dan didukung payment channel
yang beragam
• Accessibility
• Design for change
• Maximize agility and
flexibility of application
and Infrastructure
• Secure Information
• Service Orientation
93
Universitas Indonesia
No Pola Solusi Prinsip Arsitektur
• Penggunaan kembali
• Business Continuity
• User management
• Corporate data model
• Kemudahan penggunaan
• Common use application
• Interoperability
28 Implementasi aplikasi optimizer untuk
crew management
• Maximize agility and
flexibility of application
and Infrastructure
• Penggunaan kembali
• Common use application
29 Implementasi aplikasi rotation optimizer
untuk aircraft management
• Design for change
• Maximize agility and
flexibility of application
and Infrastructure
• Service Orientation
• Penggunaan kembali
• Corporate data model
30 Modernisasi pola komunikasi • Maximize agility and
flexibility of application
and Infrastructure
• Service Orientation
• Business Continuity
• Interoperability
31 Dapat dijamin bahwa message yang
dikirm sampai dengan baik sehingga
flight plan dapat dicetak
• Maximize agility and
flexibility of application
and Infrastructure
• Business Continuity
94
Universitas Indonesia
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
Revenue Management System
Network Planning and Scheduling System
Aircraft Management System
Crew Management 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
Universitas Indonesia
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
Universitas Indonesia
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.
Revenue Management System
Network Planning & Schedulling System
Aircraft Management System
Crew Management System
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
Universitas Indonesia
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
Universitas Indonesia
Proses Bisnis Pendukung
Pricing
Network Planning
Crew Management
Reservation
Ticketing
Check-in
Departure Control
Flight Operation
Catering Management
In-Flight Service Baggage Service
Revenue Management
Revenue Management System
Crew Management System
E-Briefing
PSS
PSS
PSS
PSS
PSSIBE-B2C
IBE-B2T
Network Planning & Schedulling System
FFP
Meal Monitoring
IBE-B2C
IBE-B2T
Revenue Accounting System
PSS
Maintenace & Engineering Management
Flight Connections
PSS
Proses Bisnis Inti
Aircraft management
Aircraft Management System
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
Customer Loyalty/Relationship Management
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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)
Crew Management System
IBE-B2T
IBE-Mobile
Ops Control
Mobile Check-in
FOQA
CFD
E-Briefing
Aircraft Management System
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
Universitas Indonesia
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
Application Integration
Desktop Client
Iden
tity
Man
agem
ent
Virt
ualiz
atio
n
Mobile Client (Smartphone)
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
Network Planning & Scheduling System
IBE-B2C
Deposit Management
KIOSK
Web Check-in
Crew Management System
IBE-B2T
IBE-Mobile
Ops Control
Mobile Check-in
FOQA
CFD
E-Briefing
Aircraft Management System
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
Universitas Indonesia
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
Network Planning & Scheduling System
IBE-B2C
Deposit Management
KIOSK
Web Check-in
Crew Management System
IBE-B2T
IBE-Mobile
Ops Control
Mobile Check-in
FOQA
CFD
E-Briefing
Aircraft Management System
SMS-Booking
PSS GUI
OTA-API
FIDS
Meal Monitoring
AIRCOM
Sentinel
FFP
CRM
WEB Client
Enterprise
Application Integration
Desktop Client
Iden
tity
Man
agem
ent
Virt
ualiz
atio
n
Mobile Client (Smartphone)
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
Universitas Indonesia
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
Universitas Indonesia
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
Crew Management System
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
Universitas Indonesia
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
Aircraft Management System
MQ FTP
Crew Management System
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
Universitas Indonesia
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
Network Planning & Scheduling System
Aircraft Management System
Crew Management System
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
Java Application Server
Web Server & PHP
.NET Server
Schedule
Ops
Crew
TPF
B2C
B2T
B2C
Flight
Blackbox
Web Server & PHP
Windows Message
Java Application Server
Web Server & PHP Flight Dispatch
Web Server & PHP
Java Application Server
Java Application Server
Java Application Server Deposit
Windows
Windows Flight Event
SOAP
SOAP
REST
MQ
FTP
FTP
FTP
Java Application Server
DB Conn
Java Application Server
Java Application Server
Java Application Server
Java Application Server
sMile/FFP Browser LAN/Internet Java Application Server Loyalty
FTP Customer
Data Warehouse
PSS Offline
Gambar 5.13 Platform Arsitektur Teknologi
108
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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
Application Integration
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
Universitas Indonesia
• 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
Universitas Indonesia
CloudAccess
Public
Medium Switch
Switch
Hosting Place/Virtual Machines
Storage
High EndRouter
MPLS Telkom
Other TrustedNetwork
Internet
Public UserPublic User
Mainframe
Hosting Place/Virtual Machines
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
Other TrustedNetwork
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
Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
Tabel 5.12 Analisis kesenjangan sistem informasi (sambungan)
Sistem Informasi Target
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)
Sistem Informasi Target
Deposit Management Mobile Check-in KIOSK Web Check-in
Sist
em
Info
rmas
i Sa
at
ini
Baru add add add add
119
Universitas Indonesia
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
Universitas Indonesia
Tabel 5.13 Analisis kesenjangan infrastruktur TI
Sistem Informasi Target
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
Universitas Indonesia
Tabel 5.13 Analisis kesenjangan infrastruktur TI (sambungan)
Sistem Informasi Target
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
Universitas Indonesia
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
Universitas Indonesia
• 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
Universitas Indonesia
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
Universitas Indonesia
• 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
Universitas Indonesia
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.
127 Universitas Indonesia
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
Universitas Indonesia
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
Universitas Indonesia
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.
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
adalah sebagai berikut:
• 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