TUGAS

Audit TI (A)

Oleh
1. I Wayan Gede Mayun Kepakisan
2. Desak Nyoman Hariwindaty Purwa
3. Nuria Agustin

1204505001
1204505025
1204505027

JURUSAN TEKNOLOGI INFORMASI

FAKULTAS TEKNIK UNIVERSITAS UDAYANA
2015

Tata Kelola dan Framework Tata Kelola

Penerapan Information technology (IT) dalam sistem kerja oleh berbagai
jenis perusahaan atau organisasi bertujuan untuk meningkatkan kinerja, mencapai
tujuan dan sasaran, dan meningkatkan keunggulan kompetitif organisasi.
Sementara itu, untuk dapat meningkatkan kemampuan adaptasi perusahaan atau
organisasi di era global saat ini penerapan IT menghadapi berbagai tantangan.
Karenanya penerapan IT governance (Tata Kelola) bagi perusahaan atau
organisasi sangat dibutuhkan untuk dapat menghilangkan kekurangan atau
kelemahan pada pelaksanaan kegiatan operasional dan pelayanan kepada
customer yang menjadi penghambat kinerja dan inovasi proses dan kegiatan bisnis
perusahaan. Peningkatan kinerja, keunggulan kompetitif, dan pencapaian tujuan
dan sasaran perusahaan atau organisasi dapat dicapai melalui penerapan IT
governance yang baik, namun pencapaian tersebut belum optimal tanpa dukungan
tata kelola perusahaan yang baik secara menyeluruh. Sementara itu sejak satu
dekade terakhir banyak perusahaan atau organisasi mulai mengadopsi dan
menerapkan prinsip dan cara kerja good governance dan IT Governance dalam
melaksanakan kegiatan bisnisnya. Penerapan prinsip dan cara kerja good
governance diyakini dapat meningkatkan peranan IT governance dalam
menghilangkan penghambat inovasi, meningkatkan kinerja, dan mencapai tujuan
dan sasaran perusahaan yang telah ditetapan.
Lingkup Tata Kelola
Berdasarkan laporan penelitian Meta Group tahun 2005 (Group Meta,
2005) disampaikan bahwa perusahaan-perusahaan yang mempunyai kebijakan IT
governance yang baik dapat mencapai paling sedikit 20% hasil aset perusahaan
jika dibandingkan dengan perusahaan yang IT governance-nya lebih lemah.
Sementara dari aspek kinerja perusahaan, penerapan IT governance yang baik dan
efektif juga dapat meningkatkan capaian kinerja hingga mencapai 20% (Ross, et
all: 2004). Laporan penelitian Meta Group tersebut sejalan dengan laporan dari
Asian Development Bank tahun 2004 (Sofian Efendi, 2005) yang menyatakan
bahwa good governance di Indonesia belum berhasil seperti yang diharapkan.

Sementara itu, menurut National Business Ethics Survey 2007 yang dilakukan
oleh Ethics Resource Center, sebuah survei yang menilai bagaimana etika di
tempat kerja diterapkan dari sudut pandang karyawan, ditemukan bahwa secara
umum perilaku tidak etis sangat tinggi, dan lebih dari setengah responden
menyatakan telah menyaksikan perilaku tidak etis terjadi. Selain itu, jumlah
perusahaan yang berhasil mengintegrasikan kultur etis dalam aktivitas usahanya
menurun sejak 2005. Hanya 9 persen dari perusahaan yang disurvei memiliki
kultur etis yang kuat serta berlandaskan prinsip good governance. Karenanya,
banyak yang beranggapan bahwa diperlukan peraturan yang lebih ketat dan tools
untuk mendukung dan memastikan penerapan prinsip dan cara kerja good
governance.
Tata kelola TI memiliki definisi sebagai berikut :Tata kelola TI adalah suatu
struktur dan proses yang saling berhubungan serta mengarahkan dan mengendalikan
perusahaan dalam pencapaian tujuan perusahaan melalui nilai tambah dan penyeimbangan antara risiko dan manfaat dari teknologi informasi serta prosesnya. IT
governance merupakan satu kesatuan dengan sukses dari enterprise governance
melalui peningkatan dalam efektivitas dan efisiensi dalam proses perusahaan yang
berhubungan. IT governance menyediakan struktur yang menghubungkan proses TI,
sumber daya TI dan informasi bagi strategi dan tujuan perusahaan. Lebih jauh lagi IT
governance

menggabungkan

good

(best)

practice

dari

perencanaan

dan

pengorganisasian TI, pembangunan dan pengimplemantasian, delivery dan support,

serta memantau kinerja TI untuk memastikan kalau informasi perusahaan dan
teknologi yang berhubungan mendukung tujuan bisnis perusahaan.
Menurut Weber (2000) terdapat berbagai alasan mengapa tata kelola
diperlukan bagi sebuah perusahaan, diantaranya:
1.

Kerugian akibat kehilangan data. Data me-rupakan asset yang sangat berharga bagi
setiap perusahaan. Jika data hilang karena unsure kesengajaan ataupun tanpa kesengajaan akan mengakibatkan kerugian be-sar bagi perusahaan.

2.

Kesalahan dalam pengambilan keputusan. Keputusan yang dibuat pihak manajemen

bisa terbantu dengan adanya bantuan sis-tem TI. Misalnya penggunaan Decision
Support System (DSS) sudah banyak dite-rapkan di perusahaan untuk membantu pihak manajemen dalam menentukan kepu-tusan/kebijakan yang harus dijalankan, sehingga keputusan tersebut akan mengha-silkan kinerja yang lebih baik dari bagian TI.

3.

Risiko kebocoran data. Pengolahan data yang baik akan mengurangi tingkat kebocoran data kepada pihak yang tidak memi-liki kepentingan. Kebocoran data diperusahaan bisa diminimalkan dengan cara menerapkan sistem pengolahan dan dokumentasi data yang benar.

4.

Penyalahgunaan komputer. Banyak orang pintar tetapi ada yang menggunakan kepintaran tersebut untuk mengganggu sis-tem TI pihak lain. Misalnya hacker atau
cracker adalah contoh orang pintar yang menyalahgunakan komputer untuk mengganggu sistem pihak lain.

5.

Kerugian akibat kesalahan proses perhi-tungan. Kesalahan perhitungan data bia-sanya

terjadi saat terjadi perubahan sistem komputerize lama ke sistem yang baru. Sa-ngat
sulit untuk mengetahui kesalahan per-hitungan data akibat pergantian sistem, kalaupun bisa akan membutuhkan waktu yang relatif lama.

6.

Tingginya nilai investasi TI. Tatakelola TI yang tidak menerapkan perencanaan yang
matang biasanya akan membutuhkan biaya yang besar dan kemungkinan manfaat
yang didapat dari investasi tersebut tidak optimal.

Peran dan fungsi utama dalam tata kelola TI ada dua : Pengaturan (govern)
dan Pengelolaan (manage). Pengaturan meliputi hal-hal apa yang mendasari tata
kelola tersebut, yang ditentukan melalui pendefinisian strategi dan kontrol.
Sedangkan bagaimana tata kelola tersebut dilaksanakan merupkan cakupan dari
pengelolaan yang ditentukan melalui rencana taktis dan eksekusi. Klasifikasi
kerangka kerja dalam Tata Kelola TI digambarkan seperti dibawah ini:

COBIT termasuk dalam pengaturan yang meliputi strategi dan kontrol.

Kerangka kerja tersebut fokus lebih banyak pada kontrol dan sedikit eksekusi
sehingga kepentingannya lebih pada pendefinisian strategi dan kontrol yang
umumnya dilakukan oleh manajemen tingkat atas. ITIL secara utama membahas
bagaimana

kontrol

yang

didefinisikan

agar

dapat

dilakukan

dengan

mendefinisikan rencana taktis dan eksekusi. ITIL fokus kepada pendefinisian

fungsi, operasional dan atribut organisasi yang diperlukan, agar manajemen
operasional dapat dioptimasi secara penuh dalam dua kategori utama : Service
Support Managementi dan Service Delivery Management.
Framework Tata Kelola
Output dan outcome dari IT Governance yang baik hanya dapat dicapai
jika tata kelola dikembangkan dengan menggunakan IT Framework berstandar
internasional, misalnya dengan mengimplementasikan COBIT, ITIL Management,
COSO, ISO IT Security dan sebagainya. Berikut ini akan dijelaskan beberapa
framework tata kelola.
1.

ITIL
1.1.Definisi
Information Technology Infrastructure Library (ITIL) terdiri dari satu set

konsep dan praktek yang telah dirancang untuk petunjuk Teknologi Informasi
Management Services (ITSM), Teknologi Informasi (TI) pengembangan dan
operasional TI.
Metodologi ITIL untuk praktek terbaik diletakkan dalam lima publikasi
inti. Kelima publikasi memberikan pendekatan yang sistematis dan profesional
serta rinci untuk memandu pengelolaan layanan TI. Tujuannya adalah agar
panduan praktek terbaik memungkinkan organisasi untuk memberikan layanan TI
yang sesuai serta memastikan bahwa mereka secara konsisten memenuhi tujuan
bisnis dan memberikan manfaat.
ITIL adalah kerangka umum yang menggambarkan praktek terbaik dalam
manajemen pelayanan TI. ITIL menyediakan kerangka kerja untu tata kelola IT,
dan pengelolaan dan pengendalian jasa TI. ITIL berfokus pada pengukuran terusmenerus dan peningkatan kualitas layanan TI, baik dari bisnis dan perspektif
pelanggan. Fokus ini merupakan faktor utama dalam keberhasilan ITIL di seluruh
dunia dan telah memberikan kontribusi kepada para produktif penggunaan dan

manfaat utama yang diperoleh organisasi-organisasi menyebarkan teknik dan

proses seluruh organisasi mereka. Beberapa manfaat tersebut antara lain:
1. Peningkatan pengguna dan kepuasan pelanggan dengan layanan TI
2. Peningkatan ketersediaan layanan, langsung mengarah pada peningkatan
keuntungan bisnis dan pendapatan
3. penghematan keuangan dari pengurangan ulang atau kehilangan waktu dan
dari pengelolaan sumber daya dan penggunaan
4. Peningkatan waktu ke pasar untuk produk dan layanan baru
5. Peningkatan pengambilan keputusan dan mengurangi risiko.
1.2.Sejarah
ITIL pertama kali diterbitkan antara tahun 1989 dan 1995 oleh Her
Majestys Stationery Office (HMSO) di Inggris atas nama Badan Pusat
Komunikasi

dan

Telekomunikasi

Central

Communications

and

Telecommunications Agency (CCTA). Pada awal penggunaannya terbatas pada

Inggris dan Belanda saja. Versi awal ITIL terdiri dari library 31 buku terkait yang
meliputi semua aspek penyediaan layanan TI. Antara tahun 2000 dan 2004 versi
awal ini direvisi dan diganti dengan ITIL V2; yang terdiri dari tujuh buku yang
terhubung lebih dekat dan konsisten dalam keseluruhan framework. Diikuti
dengan ITIL V3 diterbitkan pada tahun 2007, yang terdiri dari lima publikasi inti
meliputi service lifecycle. Pada tahun 2011, edisi ITIL 2011 diterbitkan untuk
mengatasi feedback, meningkatkan kejelasan dan konsistensi di lima publikasi
ITIL inti, dan memperkenalkan beberapa tambahan kecil dan memenuhi
permintaan industri. Masing-masing dari lima publikasi inti mencakup tahap
service lifecycle seperti yang ditunjukkan pada Gambar 1, dari definisi awal dan
analisis kebutuhan bisnis di ITIL Service Strategy dan ITIL Service Desaign,
melalui migrasi ke dalam lingkungan hidup dalam ITIL Service Transition, untuk
menghidupkan operasi dan peningkatan ITIL Service Operation dan ITIL
Continual Service Improvement.
1.3.Siklus Layanan pada Framework ITIL v3
Prinsip utama dalam ITIL dan seluruh tahapan siklus hidup layanan adalah
penyelarasan TI dengan mendukung bisnis. Oleh karena itu, semua solusi layanan
dan pengiriman harus didorong oleh kebutuhan bisnis dan persyaratan, sementara
mencerminkan strategi dan kebijakan organisasi penyedia layanan.

Gambar diatas menunjukkan bagaimana siklus hidup layanan dimulai dari

perubahan persyaratan dalam bisnis. Persyaratan ini diidentifikasi dan disepakati
dalam tahap strategi pelayanan dalam mengubah usulan. Setelah tahap tersebut
selesai maka dilanjutkan pada tahap desain layanan, di mana solusi layanan
diproduksi bersama-sama dengan Service Design Package (SDP) yang
mengandung segala sesuatu yang diperlukan untuk mengambil layanan ini melalui
sisa tahap siklus hidup. SDP lolos ke tahap layanan transisi, di mana layanan
dievaluasi, diuji dan divalidasi, pengetahuan layanan Sistem manajemen (SKMS)
diperbarui, dan layanan dialihkan ke lingkungan hidup, dimana memasuki tahap
service operation. Jika memungkinkan, layanan terus menerus melakukan
perbaikan, mengidentifikasi peluang untuk perbaikan kelemahan atau kegagalan
dimana saja dalam salah satu tahap siklus hidup.
Ada peran generik dan peran khusus yang terlibat dalam setiap tahap atau
proses lifecycle. Kunci dari peran generik dijelaskan sebagai berikut:
1.

Pemilik Proses bertanggung jawab untuk memastikan bahwa proses sesuai dengan
tujuan, yaitu bahwa ia mampu memenuhi tujuannya; bahwa itu dilakukan sesuai
dengan standar yang telah disepakati dan didokumentasikan; dan memenuhi
tujuan dari definisi proses.

2.

Proses manager bertanggung jawab untuk manajemen operasional proses.

Mungkin ada beberapa manajer proses untuk satu proses dan peran manajer
proses sering ditugaskan untuk orang yang sama melakukan peran pemilik proses.

3.

Proses praktisi bertanggung jawab untuk melaksanakan satu atau lebih kegiatan
proses. Peran Proses praktisi dapat dikombinasikan dengan peran manajer proses,
jika sesuai.

4.

Pemilik layanan bertanggung jawab kepada pelanggan untuk inisiasi, transisi, dan
pemeliharaan serta dukungan dari layanan tertentu; dan bertanggung jawab
kepada direktur IT atau direktur manajemen layanan untuk pengiriman layanan TI
yang spesifik. Kepemilikan layanan sangat penting untuk manajemen layanan dan
satu orang dapat memenuhi peran pemilik layanan untuk lebih dari satu layanan.
Semua peran bertanggung jawab atas kegiatan. Namun, layanan, proses
dan kegiatan komponen berjalan melalui seluruh organisasi, setiap kegiatan harus
jelas dipetakan ke peran yang ditetapkan. Untuk mendukung hal ini, model RACI
atau 'otoritas matriks' dapat digunakan untuk menentukan peran dan tanggung
jawab dalam kaitannya dengan proses dan kegiatan.

Kelima bagian ITIL yang seperti disebutkan diatas biasanya disebut juga
sebagai bagian dari sebuah siklus. Dikenal pula dengan sebutan Sikuls Layanan
ITIL. Secara singkat, masing-masing bagian dijelaskan sebagai berikut.

1.3.1

Service Strategy
Service Strategy

bertujuan

untuk

menentukan

rencana

dengan

menggunakan satu set prinsip yang jelas sehingga akan memberikan solusi untuk
masalah bisnis dalam situasi tertentu. Hal ini difokuskan pada nilai ke pelanggan
dan mengidentifikasi aset strategis yang akan digunakan untuk keunggulan
kompetitif. Mencapai pemahaman tentang kebutuhan pelanggan, dalam hal
kebutuhan apa, kapan dan mengapa, juga membutuhkan pemahaman yang jelas
tentang siapa yang yang ada atau potensial pelanggan. Penyedia layanan mungkin
ada dalam suatu organisasi semata-mata untuk memberikan pelayanan kepada
salah satu unit usaha tertentu, atau layanan beberapa unit bisnis, atau dapat
beroperasi sebagai layanan eksternal penyedia melayani beberapa bisnis eksternal.
Strategi yang diadopsi harus memenuhi tujuan strategis penyedia layanan.
Terlepas dari konteks di mana penyedia layanan beroperasi, strategi pelayanan
perusahaan juga harus didasarkan pada pengakuan yang jelas dari adanya
persaingan, kesadaran bahwa masing-masing pihak memiliki pilihan, dan

pandangan tentang bagaimana penyedia layanan akan membedakan dirinya dari

kompetisi. Semua penyedia layanan memerlukan strategi pelayanan.
ITIL Service Strategi duduk di inti dari siklus hidup ITIL. Ini menetapkan
bimbingan untuk semua penyedia layanan TI dan pelanggan mereka, untuk
membantu mereka beroperasi dan berkembang dalam jangka panjang dengan
membangun yang jelas strategi pelayanan, dengan pemahaman yang tepat:
a. Apa layanan yang harus ditawarkan
b. Untuk siapa jasa harus ditawarkan
c. Bagaimana pasar internal dan eksternal untuk layanan mereka harus
dikembangkan
d. Persaingan yang ada dan potensi di pasar ini, dan tujuan yang akan
membedakan nilai apa penyedia layanan atau bagaimana hal itu disediakan
e. Bagaimana pelanggan dan para pemangku kepentingan akan melihat dan
mengukur nilai, dan bagaimana nilai ini akan dibuat
f. Bagaimana sumber keputusan layanan dapat dilakukan sehubungan
dengan penggunaan berbagai jenis penyedia layanan
g. Bagaimana visibilitas dan kontrol atas penciptaan nilai akan dicapai
melalui pengelolaan keuangan
h. Bagaimana bisnis yang kuat kasus akan dibuat untuk mengamankan
strategis investasi dalam aset layanan dan kemampuan manajemen layanan
i. Bagaimana alokasi sumber daya yang tersedia akan disetel untuk efek
yang optimal di seluruh portofolio layanan
j. Bagaimana kinerja pelayanan akan diukur.
1.3.1.1.

Proses dan Kegiatan Utama

Proses-proses yang dicakup dalam Service Strategy, di samping topiktopik di atas adalah:
1.

Strategy management for IT Services

Strategi manajemen untuk layanan TI memproduksi dan mempertahankan

semua rencana strategi dan memastikan mereka diterjemahkan ke dalam taktis dan
rencana operasional. Hal ini juga memperhitungkan setiap perubahan lingkungan
bisnis untuk memastikan strategi pelayanan tetap relevan. Tujuan dari strategi
layanan

untuk

mengartikulasikan

bagaimana

layanan

penyedia

akan

memungkinkan organisasi untuk mencapai hasil bisnis dan cara yang paling
efektif dan efisien untuk mengelola layanan ini. Tujuan dari manajemen strategi
Proses layanan TI adalah untuk memastikan bahwa strategi didefinisikan dan
mencapai tujuannya.

2.

Service portfolio management

Tujuan dari layanan manajemen portofolio adalah untuk memastikan

bahwa penyedia layanan memiliki campuran yang tepat dari layanan untuk
menyeimbangkan investasi TI dengan kemampuan untuk memenuhi hasil bisnis.
Layanan manajemen portofolio melibatkan manajemen proaktif investasi di
seluruh siklus hidup layanan. Ini adalah proses yang berkelanjutan, yang meliputi
langkah-langkah berikut:
a.

Define, membuat inventarisasi jasa, pastikan kasus bisnis ada, dan

b.

memvalidasi data portofolio

Analyse, Analisis portofolio

c.

memprioritaskan, dan keseimbangan suplai dan kebutuhan

Approve, menyetujui portofolio yang diusulkan Finalisasi, dan wewenang

d.

pelayanan dan sumber daya.

Charter, berkomunikasi keputusan, mengalokasikan sumber daya dan

maksimalkan,

menyelaraskan

dan

layanan charter.
3.

Financial management for IT services

Manajemen keuangan meliputi fungsi dan proses bertanggung jawab untuk

mengelola anggaran, akuntansi dan persyaratan pengisian penyedia layanan TI.

Manajemen keuangan menyediakan bisnis dan IT dengan kuantifikasi, dalam hal
keuangan, dari nilai Layanan TI, nilai aset yang mendasari penyediaan layanan
tersebut, dan kualifikasi peramalan operasional. Tujuan dari manajemen keuangan
untuk layanan TI adalah untuk mengamankan pendanaan untuk merancang,
mengembangkan dan memberikan layanan yang memenuhi strategi organisasi.
Manajemen financial IT memiliki tanggung jawab dan kegiatan tidak hanya dalam
pembiayaan IT dan domain akuntansi. Banyak bagian dari organisasi berinteraksi
untuk

menghasilkan

dan

menggunakan

informasi

financial

IT dengan

menggabungkan, berbagi dan menjaga Data keuangan yang mereka butuhkan.

4.
Demand management
Permintaan manajemen merupakan aspek penting dari manajemen
pelayanan. Permintaan buruk dikelola merupakan sumber risiko bagi penyedia
jasa karena ketidakpastian permintaan. Kelebihan kapasitas menghasilkan biaya
tanpa menciptakan nilai yang menyediakan dasar untuk cost recovery. Tujuan dari
manajemen permintaan adalah untuk memahami dan pengaruh permintaan

pelanggan untuk layanan dan penyediaan kapasitas untuk memenuhi tuntutan.

Pada tingkat strategis ini dapat melibatkan analisis pola kegiatan usaha dan profil
pengguna. Pada tingkat taktis dapat melibatkan penggunaan diferensial pengisian
untuk mendorong pelanggan menggunakan layanan TI pada waktu kurang sibuk.
Sebuah paket tingkat layanan mendefinisikan tingkat utilitas dan garansi untuk
paket layanan dan dirancang untuk memenuhi kebutuhan Pola kegiatan usaha.
5.
Business relationship management
Tujuan dari proses manajemen hubungan bisnis ada dua, yaitu:
a.

Membangun dan mempertahankan hubungan bisnis antara penyedia

layanan dan pelanggan berdasarkan pemahaman pelanggan dan kebutuhan

b.

bisnis
Mengidentifikasi kebutuhan pelanggan dan memastikan bahwa layanan
penyedia mampu memenuhi kebutuhan tersebut sebagai perubahan
kebutuhan bisnis.
Manajemen hubungan bisnis memungkinkan link yang efektif antara

penyedia layanan dan pelanggan di kedua strategis dan tingkat taktis. Bekerja
sama dengan manajemen permintaan dan proses layanan manajemen portofolio,
itu menjamin penyedia layanan memahami kebutuhan bisnis dan terus fokus pada
kepuasan pelanggan.
1.3.2

Service Design
Tujuan dari Service design adalah untuk memastikan bahwa baru atau

diubahnya layanan dirancang untuk memenuhi perubahan persyaratan dari bisnis.

Kegiatan utama dalam tahap Service design termasuk perencanaan dan koordinasi
kegiatan desain, memastikan desain yang konsisten, sistem informasi manajemen
pelayanan, arsitektur, teknologi, proses, informasi dan metrik, production of
service design packages (SDPs), pengelolaan interface, dan peningkatan kegiatan
desain layanan dan proses. ITIL service design menyediakan:
1.
Pedoman desain dan pengembangan layanan dan praktek manajemen
2.

pelayanan
Prinsip-prinsip desain dan metode untuk mengubah strategi tujuan menjadi
portofolio layanan dan aset layanan.

1.3.2.1 Proses dan Kegiatan Utama

Proses-proses yang dicakup dalam Service Design, di samping topik-topik

di atas adalah:
1.

Design coordination
Tujuan dari Design coordination adalah untuk memastikan dari tahap

desain terpenuhi. Design coordination menyediakan satu titik koordinasi dan

kontrol untuk semua kegiatan desain dan proses. Kegiatan koordinasi desain
terbagi dalam dua kategori:
a. Kegiatan yang berkaitan dengan layanan desain secara keseluruhan yang
dapat dilakukan dengan manajer proses koordinasi desain.
b. Kegiatan yang berkaitan dengan masing-masing desain individu yang
mungkin dilakukan oleh seorang manajer proyek atau individu lain dengan
tanggung jawab langsung untuk proyek atau perubahan, dengan bantuan
2.

dan bimbingan dari manajer proses koordinasi desain.

Service catalogue management
Service catalogue management menyediakan sumber utama informasi

pada layanan TI yang dikirimkan ke bisnis dengan penyedia layanan organisasi,

memastikan bahwa area bisnis dapat melihat sebuah gambaran yang konsisten
akurat dari layanan TI yang tersedia. Tujuan dari Service catalogue management
adalah untuk menyediakan sumber informasi yang konsisten tentang semua jasa
yang disepakati, dan memastikan bahwa banyak tersedia bagi mereka yang
berwenang

untuk

mengaksesnya.

Disarankan

bahwa

penyedia

layanan

mendefinisikan beberapa pandangan dari katalog layanan. Dua pandangan yang

paling umum adalah:
a.

Bisnis atau tampilan katalog layanan pelanggan. Berisi rincian layanan TI

b.

dikirim ke pelanggan (jasa customer-facing).

Teknis atau mendukung layanan tampilan katalog Berisi rincian dari
pendukung layanan TI disampaikan dan link ke layanan pelanggan,
configuration items (CI) dan lainnya yang mendukung untuk pemberian
layanan.
Informasi kunci dalam proses Service catalogue management yang

terkandung dalam katalog layanan. Input utama untuk informasi ini berasal dari
portofolio layanan dan bisnis baik manajemen hubungan bisnis atau tingkat
layanan proses manajemen.
3.

Service level management

Service level management (SLM) melakukan negosiasi, menyetujui dan

dokumen target layanan TI yang sesuai dengan bisnis di tingkat layanan perjanjian
(SLA) dan kemudian memantau dan menghasilkan laporan pengiriman terhadap
tingkat disepakati pelayanan. Tujuan dari proses SLM adalah untuk memastikan
bahwa semua operasional layanan dan kinerja mereka diukur secara konsisten,
secara profesional di seluruh organisasi TI, dan bahwa layanan dan laporan yang
dihasilkan memenuhi kebutuhan bisnis dan pelanggan. Informasi utama yang
disediakan oleh proses SLM termasuk SLA, perjanjian tingkat operasional (Olas)
dan dukungan perjanjian lainnya, dan produksi rencana peningkatan pelayanan
dan rencana mutu pelayanan.
4.
Availability management
Tujuan dari manajemen ketersediaan adalah untuk menyediakan titik
Fokus dan manajemen untuk semua masalah ketersediaan untuk layanan,
komponen dan sumber daya, memastikan bahwa target ketersediaan di semua
bidang yang diukur dan dicapai, dan bahwa mereka cocok atau melebihi saat ini
dan masa depan yang disepakati kebutuhan bisnis dengan cara yang hemat biaya.
Manajemen ketersediaan berlangsung di dua saling tingkatan, yaitu ketersediaan
layanan dan ketersediaan komponen, dan bertujuan untuk terus mengoptimalkan
dan proaktif meningkatkan ketersediaan layanan TI dan organisasi pendukungnya.
Ada dua aspek utama:
a. Kegiatan Reaktif yaitu monitoring, pengukuran, analisis dan manajemen
acara, insiden dan masalah yang melibatkan Layanan yang tidak tersedia
b. kegiatan proaktif yaitu perencanaan proaktif, desain, tekomendasi dan
peningkatan ketersediaan.
Kegiatan pengelolaan ketersediaan mempertimbangkan ketersediaan,
kehandalan, pemeliharaan dan servis pada kedua layanan dan tingkat komponen,
terutama yang mendukung fungsi bisnis. Proses manajemen ketersediaan
didasarkan di sekitar sistem informasi manajemen ketersediaan yang berisi semua
pengukuran dan informasi yang diperlukan untuk mendukung kegiatan
ketersediaan, menghasilkan rencana ketersediaan dan memberikan informasi yang
sesuai dengan bisnis tingkat layanan.
5.

Capacity management

Manajemen Kapasitas meliputi bisnis, layanan dan komponen Manajemen

Kapasitas di seluruh siklus hidup layanan. Sebuah kunci keberhasilan Faktor
dalam mengelola kapasitas adalah memastikan bahwa hal ini dianggap selama
tahap desain. Tujuan dari manajemen kapasitas untuk menyediakan titik Fokus
dan manajemen untuk semua kapasitas dan terkait masalah kinerja, yang berkaitan
dengan kedua layanan dan komponen, dan untuk mencocokkan kapasitas TI
dengan tuntutan bisnis yang telah disepakati. Capacity management information
system (CMIS) adalah landasan proses manajemen kapasitas yang sukses.
Informasi yang terkandung dalam CMIS disimpan dan dianalisis oleh semua subproses manajemen kapasitas untuk penyediaan teknis dan manajemen laporan,
termasuk rencana kapasitas.
6.

IT service continuity management

Sebagai teknologi adalah komponen inti dari sebagian besar proses bisnis,

ketersediaan berkelanjutan TI sangat penting untuk kelangsungan hidup bisnis

secara keseluruhan. Hal ini dicapai dengan memperkenalkan langkah-langkah
pengurangan risiko dan pilihan pemulihan. Pemeliharaan dari kemampuan
pemulihan sangat penting jika ingin tetap efektif. Tujuan dari IT service continuity
management (ITSCM) adalah untuk mempertahankan kemampuan pemulihan
yang sedang berlangsung tepat dalam layanan IT untuk mencocokkan kebutuhan,
persyaratan dan rentang waktu bisnis. ITSCM mencakup serangkaian kegiatan di
seluruh siklus hidup untuk memastikan bahwa, setelah layanan kontinuitas dan
pemulihan rencana dikembangkan, mereka terus selaras dengan kelangsungan
bisnis rencana dan prioritas bisnis. Pemeliharaan strategi kebijakan ITSCM yang
tepat dan Rencana ITSCM selaras dengan rencana bisnis adalah kunci
keberhasilan proses ITSCM. Hal ini dapat dicapai dengan penyelesaian analisis
dampak bisnis dan latihan manajemen risiko.
7.

Information security management

Information security management (ISM) perlu dipertimbangkan dalam

kerangka tata kelola perusahaan secara keseluruhan. Perusahaan pemerintahan

adalah himpunan tanggung jawab dan praktek dilaksanakan oleh dewan dan
manajemen eksekutif dengan tujuan memberikan arahan strategis, memastikan
bahwa tujuan dicapai, memastikan bahwa risiko dikelola dengan tepat, dan
memverifikasi bahwa sumber daya perusahaan digunakan secara efektif. Tujuan

dari proses ISM adalah untuk menyelaraskan keamanan dengan keamanan bisnis
TI dan memastikan bahwa keamanan informasi secara efektif dikelola dalam
semua kegiatan pelayanan dan jasa manajemen, seperti:
a. Informasi tersedia dan dapat digunakan bila diperlukan (ketersediaan)
b. Informasi diamati oleh atau diungkapkan hanya orang-orang yang
memiliki hak untuk tahu (kerahasiaan)
c. Informasi lengkap, akurat dan dilindungi terhadap modifikasi yang tidak
sah (integritas)
d. transaksi bisnis, serta pertukaran informasi, dapat dipercaya (keaslian dan
non-repudiation).
ISM mempertahankan dan memberlakukan kebijakan secara keseluruhan,
bersama-sama mendukung kontrol dalam suatu manajemen keamanan sistem
informasi, sejalan dengan kebijakan keamanan bisnis dan strategi.
8.

Supplier management
Proses manajemen pemasok memastikan bahwa pemasok dan layanan

yang mereka berikan dikelola untuk mendukung target layanan TI dan ekspektasi
bisnis. Tujuan dari proses manajemen pemasok adalah untuk mendapatkan nilai
uang dari pemasok dan untuk memastikan bahwa pemasok tampil dengan target
yang terkandung dalam kontrak dan perjanjian mereka sesuai dengan semua
persyaratan dan kondisi. Proses ini mengkategorikan pemasok dan kontrak dalam
hal nilai, penting, risiko dan dampak, dan mengelola mereka sesuai dengan
kekritisan mereka untuk pengiriman keseluruhan layanan TI. Sistem pemasok dan
manajemen kontrak informasi adalah sumber penting informasi tentang pemasok
dan kontrak. Sistem harus berisi semua informasi yang diperlukan untuk
manajemen pemasok, kontrak dan jasa terkait.
1.3.3

Service Transition
Tujuan dari Service Transition adalah menyediakan panduan kepada

organisasi TI untuk dapat mengembangkan serta kemampuan untuk mengubah

hasil desain layanan TI baik yang baru maupun layanan TI yang diubah
spesifikasinya ke dalam lingkungan operasional. Kegiatan utama selama tahap ini
layanan siklus hidup termasuk perencanaan dan pengelolaan perubahan dan rilis,
mengelola risiko, mentransfer pengetahuan, dan memastikan bahwa nilai bisnis
yang diharapkan disampaikan. Layanan transisi berfokus pada pelaksanaan semua
aspek layanan, memastikan bahwa layanan baru atau diubah memenuhi

persyaratan pelanggan dan dapat dikelola oleh penyedia layanan. Ini

membutuhkan pemahaman yang cukup tentang:
1. nilai bisnis potensial
2. Identifikasi semua kepentingan stakeholdes dalam pemasok, pelanggan
dan daerah lain.
3. Pelaksanaan dan adaptasi dari desain layanan, termasuk mengatur
modifikasi desain, di mana perlu terdeteksi selama masa transisi.
1.3.3.1 Proses dan Kegiatan Utama
Proses yang dijelaskan dalam ITIL Service Transition dapat dikategorikan
menjadi dua kelompok, berdasarkan sejauh mana kegiatan proses berlangsung
selama tahap transisi layanan dari siklus hidup layanan. Beberapa proses yang
penting selama tahap Service Transition, namun mempengaruhi dan mendukung
semua tahapan siklus hidup layanan antara lain: Manajemen perubahan, aset
Layanan dan manajemen konfigurasi, dan Manajemen pengetahuan. Proses lain
yang sangat terfokus dalam tahap siklus hidup layanan adalah perencanaan dan
dukungan Transisi, manajemen rilis dan penyebaran, Layanan validasi dan
pengujian, dan Perubahan evaluasi.
Proses-proses yang dicakup dalam Service Transition yaitu:
1.
Transition planning and support
2.
Change management
3.
Service asset and configuration management (SACM)
4.
Release and deployment management
5.
Service validation and testing
6.
Change evaluation
7.
Knowledge management
1.3.4

Service Operation
Tujuan dari service operation untuk memberikan layanan kepada

pengguna dan pelanggan serta untuk mengelola aplikasi, teknologi dan

infrastruktur

yang

mendukung

pengiriman

layanan.

service

strategy

mendefinisikan nilai, service design memberikan layanan desain untuk nilai itu,
service transition membawa desain ke layanan langung, dan kemudian itu adalah
tanggung jawab staf service operation untuk memastikan bahwa layanan dan nilai
telah disampaikan. Fase service operation dalam siklus hidup yang berhubungan
hampir eksklusif dengan pengguna. Service operation juga satu-satunya fase
dalam layanan siklus hidup yang memiliki fungsi yang ditetapkan di dalamnya.

Ada empat fungsi yaitu: service desk, manajemen teknis, manajemen aplikasi dan
manajemen operasional TI.
1.3.4.1 Proses dan Kegiatan Utama
Proses-proses yang dicakup dalam service operation, di samping topiktopik di atas adalah:
1.
2.
3.
4.
5.
6.
1.3.5

Event management
Incident management
Request fulfilment
Problem management
Access management
Common service operation activities
Continual Service Improvement
Continual service improvement (CSI) berkaitan dengan mempertahankan

nilai bagi pelanggan melalui evaluasi terus-menerus dan peningkatan kualitas

layanan dan kematangan keseluruhan dari siklus hidup layanan ITSM dan proses
yang mendasari CSI mengkombinasikan prinsip-prinsip, praktek dan metode dari
kualitas manajemen, manajemen perubahan dan peningkatan kemampuan, bekerja
untuk meningkatkan setiap tahap dalam siklus hidup layanan. Bagi banyak
organisasi, CSI menjadi proyek ketika sesuatu telah gagal dan sangat berdampak
pada bisnis. Ketika masalah teratasi konsep ini segera dilupakan sampai terjadi
kegagalan utama berikutnya. Pendekatan CSI ditunjukkan pada Gambar dibawah
ini:

CSI menyediakan cara untuk organisasi dalam mengidentifikasi dan

mengelola perbaikan yang tepat dengan kontras posisi saat ini, dan nilai itu
menyediakan untuk bisnis, dengan tujuan jangka panjang, mengidentifikasi
kesenjangan yang ada. Hal ini dilakukan secara terus menerus untuk mengatasi
perubahan kebutuhan bisnis dan teknologi untuk memastikan keselarasan
berkelanjutan dan peningkatan layanan TI.
1.3.5.1 Proses dan Kegiatan Utama
CSI mendefinisikan tiga bidang utama untuk pelaksanaan yang efektif dari
perbaikan berkelanjutan yaitu proses perbaikan tujuh langkah, pengukuran
layanan dan pelaporan layanan. Dibawah ini akan diuraikan lebih lanjut
1.
Seven-step improvement process
2.
Service measurement
3.
Service Reporting
2.

TOGAF
TOGAF atau The Open Group Architecture Framework adalah metode

yang komprehensif dan satu set alat yang mendukung bagi pengembangan
arsitektur enterprise. TOGAF telah dikembangkan dan dikelola oleh anggota The
Open Group. Perkembangan asli TOGAF Versi 1 tahun 1995 didasarkan pada
Technical Architecture Framework for Information Management (TAFIM), yang

dikembangkan oleh Departemen Pertahanan Amerika Serikat. Departemen

Pertahanan memberikan The Open Group izin eksplisit dan dorongan untuk
membuat TOGAF dengan membangun di TAFIM, yang itu sendiri merupakan
hasil dari upaya pengembangan bertahun-tahun dan investasi jutaan dolar dari
Pemerintah AS. TOGAF diterbitkan pada server web publik. Hal ini dapat
digunakan secara cuma-cuma oleh organisasi untuk menggunakannya secara
internal untuk menciptakan arsitektur.
TOGAF memberikan metode dan alat untuk membantu dalam penerimaan,
produksi, penggunaan, dan pemeliharaan arsitektur enterprise. Hal ini didasarkan
pada model proses berulang yang didukung oleh best practices dan satu set yang
dapat digunakan kembali dari aset arsitektur yang sudah ada.
TOGAF mencakup tetapi tidak benar-benar mengikuti terminologi
ISO/IEC 42010:2007. Di TOGAF, '' arsitektur '' memiliki dua arti tergantung pada
konteks sebagai berikut:
1.

Penjelasan formal sistem, atau rencana rinci dari sistem pada tingkat komponen

2.

untuk memandu pelaksanaannya.

Struktur komponen, hubungan antar mereka, dan prinsip-prinsip serta pedoman
yang mengatur desain dan evolusinya dari waktu ke waktu.
Ada empat domain arsitektur yang umum diterima sebagai himpunan
bagian dari arsitektur perusahaan secara keseluruhan, yang semuanya dirancang
TOGAF untuk mendukung:

1.

Arsitektur Bisnis mendefinisikan strategi bisnis, tata kelola, organisasi, dan proses

2.

bisnis utama.
Arsitektur Data menggambarkan struktur aset data logis dan fisik organisasi dan

3.

sumber daya manajemen data.

Arsitektur Aplikasi menyediakan cetak biru untuk sistem aplikasi individu untuk
digunakan, interaksi mereka, dan hubungan mereka dengan proses bisnis inti

4.

organisasi.
Teknologi Arsitektur menggambarkan perangkat lunak dan perangkat keras
kemampuan logis yang diperlukan untuk mendukung penyebaran layanan bisnis,
data, dan aplikasi. Ini termasuk infrastruktur TI, middleware, jaringan,
komunikasi, pengolahan, standar, dll.

Architecture Development Method (ADM) TOGAF menggambarkan suatu

metoda untuk mengembangkan Enterprise Architecture, dan merupakan kunci
atau inti TOGAF. ADM adalah metoda generik untuk pengembangan arsitektur
yang berhubungan dengan kebanyakan kebutuhan sistem dan organisasi. Akan
tetapi, seringkali perlu memodifikasi atau mengembangkan ADM untuk
menyesuaikan kebutuhan-kebutuhan yang spesifik.

Gambar 1. Fase ADM

ADM terdiri atas sembilan fase. Setiap fase menggambarkan kumpulan

aktifitas yang memungkinkan sponsor dan para stakeholder mencapai keputusan
dalam EA. Tim bisnis dan TI bekerja sama, dari fase ke fase, untuk membuat dan
mengelola EA sepanjang siklus ADM. ADM bersifat iteratif, dinamis, dan
berkelanjutan. Output dari fase sebelumnya menjadi input pada fase selanjutnya.
Hal ini dikelola dengan fase Requirements Management.
ADM mendefinisikan urutan yang direkomendasikan untuk berbagai fase
dan langkah dalam pengembangan arsitektur, tetapi tidak merekomendasikan
lingkupyang harus ditetapkan oleh organisasi yang bersangkutan. Berikut ini
adalah tahapan untuk mengembangkan arsitektur yang terdapat dalam ADM:
1.

Preliminary Phase: Frameworks and Principles (Scoping and identifying

resource)

Dimulai dengan preliminary phase, membuat lingkup enterprise dan

mengidentifikasi sumber daya yang dibutuhkan untuk membuat dan menghasilkan
EA. Pada tahap ini orang-orang tertentu, proses, perangkat dan tata kelola
dialokasikan kepada pekerjaan pengembangan EA.
Satu dari keputusan kunci adalah fokus/cakupan pada upaya arsitektur,
dalam kaitan luasnya enterprise yang diliput, seperti sektor bisnis, unit
bisnis/organisasi yang spesifik. Faktor penting dalam konteks ini adalah
meningkatnya kecenderungan untuk pengembangan arsitektur besar-besaran
dilakukan dalam bentuk federated architecture yang dengan bebas
mengembangkan,

merawat,

dan

mengelola

arsitektur

yang

kemudian

diintegrasikan dalam satu framework meta-architecture. Framework seperti itu

menetapkan prinsip-prinsip untuk interoperabilitas, migrasi, dan penyesuaian. Hal
ini memungkinkan unit bisnis tertentu untuk mempunyai arsitektur yang
dikembangkan dan dikelola sebagai proyek arsitektur yang berdiri sendiri.
Fase ini adalah tentang menetapkan bagaimana melakukan arsitektur
terkait dengan enterprise. Ada dua aspek utama yaitu menetapkan framework
yang digunakan dan menetapkan prinsip arsitektur yang akan menginformasikan
pekerjaan arsitektur. Pendekatan enterprise untuk menggunakan kembali aset-aset
arsitektur adalah bagian kunci dari definisi framework dan prinsip arsitektur. Pada
umumnya prinsip akan menyatakan kebijakan penggunaan kembali; dan
framework akan menjelaskan bagaimana penggunaan kembali itu efektif. Fase ini
menetapkan prinsip arsitektur yang akan membentuk bagian pembatas pada
pekerjaan arsitektur yang dilakukan.
a. Input pada fase ini adalah:

TOGAF ADM

Framework arsitektur yang lain, jika diperlukan

Strategi bisnis, prinsip bisnis, tujuan bisnis, dan driver bisnis, jika sudah ada

Strategi tata kelola TI, jika sudah ada

Prinsip arsitektur, jika sudah ada

Prinsip yang dipakai, datang dari arsitektur yang lain

b. Langkah-langkah pada fase ini:

TOGAF ADM adalah satu metoda umum, dimaksudkan untuk digunakan

oleh berbagai macam enterprise berbeda, dan bersama dengan berbagai macam
framework arsitektur lain, jika diperlukan.
c. Output:

2.

Definisi framework

Prinsip arsitektur

Uraian baru, atau referensi kepada prinsip bisnis, tujuan bisnis, dan driver bisnis
Phase A: Architecture Vision (Envisioning the future state)
Langkah penting selanjutnya adalah membuat visi EA masa depan. Untuk
itu, digunakan skenario bisnis untuk meninjau visi, strategi dan pendorong bisnis
lalu dihasilkan kumpulan kebutuhan bisnis untuk enterprise masa depan. Secara
normal, elemen kunci dari visi arsitektur, seperti visi, misi, strategi dan tujuan,
didokumentasikan sebagai bagian dari strategi bisnis atau aktifitas rencana
enterprise yang mempunyai siklusnya sendiri.
Aktifitas dalam fase A berhubungan dengan verifikasi dan pemahaman
strategi dan tujuan bisnis yang didokumentasikan, menetapkan lingkup arsitektur,
bagaimana membuat visi dan memperoleh persetujuan. Visi arsitektur meliputi
deskripsi tingkat-tinggi lingkungan saat ini dan target dari perspektif bisnis dan
teknik.
a. Input:
Permintaan untuk pekerjaan arsitektur
Strategi bisnis, tujuan bisnis, dan driver bisnis
Prinsip arsitektur, termasuk prinsip bisnis, jika sebelumnya sudah ada
Enterprise continuum,

dokumentasi

arsitektur saat

ini (deskripsi

framework, arsitektur, baseline, dan sebagainya)

b. Langkah-langkah:
Menetapkan proyek
Melakukan prosedur yang perlu untuk mengamankan proyek enterprise
keseluruhan, pengesahan manajemen perusahaan, dan dukungan serta
komitmen yang diperlukan manajemen lini. Meliputi referensi kepada

framework tata kelola TI untuk enterprise, menjelaskan bagaimana proyek

ini berhubungan dengan framework.
Identifikasi tujuan dan driver bisnis
Jika hal ini telah didefinisikan dalam enterprise, pastikan bahwa definisi
yang ada jelas. Jika tidak, kembali kepada awal pernyataan pekerjaan
arsitektur dan definisikan hal-hal yang penting sejak awal dan pastikan
pengesahannya oleh manajemen organisasi.
Review prinsip arsitektur, termasuk prinsip bisnis
Review prinsip pada kondisi di mana arsitektur baseline akan
dikembangkan. Prinsip arsitektur secara normal berdasarkan pada prinsip
bisnis yang dikembangkan sebagai bagian dari fase Preliminary.
c. Menetapkan lingkup
Tetapkan apa yang ada di dalam dan di luar lingkup upaya arsitektur
bisnis. Masalah-masalah yang terlibat dalam lingkup arsitektur, secara
khusus menggambarkan:

Luas cakupan enterprise o Level detil yang ditetapkan

Domain arsitektur spesifik yang diliput (bisnis, data, aplikasi, teknologi)

Tingkat masa datang yang dituju

Aset arsitektur yang akan diungkit, atau dipertimbangkan untuk

digunakan, dari Enterprise Continuum organisasi:
o Aset yang diciptakan dalam iterasi sebelum siklus ADM dalam
enterprise
o Aset yang tersedia di tempat lain dalam industri (framework lain,
model sistem, model industri vertikal, dan sebagainya)

d. Menetapkan batasan
Menetapkan batasan yang harus berhubungan dengan batasan enterprise
keseluruhan dan proyek yang spesifik (waktu, jadwal, sumberdaya).
Batasan enterprise keseluruhan akan diinformasikan oleh prinsip arsitektur
dan bisnis yang dikembangkan dalam fase preliminary atau dijelaskan
sebagai bagian dari fase A.
Identifikasi

stakeholder,

kebutuhan

bisnis

dan

visi

arsitektur

Mengidentifikasi stakeholder dan sasaran mereka, kebutuhan bisnis kunci

yang dituju dalam upaya arsitektur, dan mengartikulasikan visi arsitektur
Mengembangkan pernyataan pekerjaan arsitektur dan mengamankan
persetujuan
Berbasis pada tujuan, fokus, lingkup, dan batasan, menentukan domain
arsitektur yang harus dikembangkan, tingkat detil, dan pandangan
arsitektur yang harus dibangun. Memperkirakan sumber-sumber daya yang
diperlukan, mengembangkan satu roadmap dan membuat jadwal
pengembangan yang diusulkan, dan mendokumentasikannya dalam
pernyataan pekerjaan arsitektur. Mengamankan persetujuan formal
pernyataan pekerjaan arsitektur dalam prosedur-prosedur tata kelola yang
sesuai.
e. Output:
Pernyataan pekerjaan arsitektur yang disetujui, termasuk:
Lingkup dan batasan
Rencana untuk pekerjaan arsitektur

Pernyataan tujuan bisnis dan driver strategi yang diperbaiki

Prinsip arsitektur, termasuk prinsip bisnis

Visi arsitektur, termasuk:

Arsitektur bisnis baseline versi 0.1

Arsitektur teknologi baseline versi 0.1 o Arsitektur data baseline

versi 0.1

Arsitektur aplikasi baseline versi 0.1 o Arsitektur bisnis target versi

0.1

Arsitektur teknologi target versi 0.1 o Arsitektur data target versi

0.1

3.

Arsitektur aplikasi target versi 0.1

Phase B: Business Architecture

Pengetahuan tentang arsitektur bisnis adalah prasyarat untuk pekerjaan
arsitektur dalam domain lainnya yaitu data, aplikasi, dan teknologi. Fase ini

membuat arsitektur bisnis yang meliputi proses bisnis, layanan, fungsi, organisasi
dan strategi.
a. Input:
Output pada fase A
Permintaan untuk pekerjaan arsitektur
Enterprise continuum
b. Langkah-langkah:
Tingkat detil dalam fase ini akan tergantung kepada lingkup dan
tujuan upaya arsitektur keseluruhan. Langkah-langkah kunci dalam fase B
adalah sebagai berikut:
Mengembangkan deskripsi arsitektur bisnis baseline
Mengidentifikasi model, sudut pandang, dan tool acuan
Membuat model arsitektur
Memilih blok bangunan (building block) arsitektur bisnis
Melakukan review model arsitektur
Me-review kriteria non-fungsional (kualitatif)
Melengkapi arsitektur bisnis
Melakukan analisis celah (gap) dan membuat laporan
c. Output:
Pernyataan pekerjaan arsitektur, diperbaharui jika perlu
Prinsip bisnis yang divalidasi, tujuan bisnis, dan driver strategi
Arsitektur bisnis target versi 1.0 (dirinci), termasuk:

struktur organisasiidentifikasi lokasi bisnis dan menghubungkannya

dengan unit organisasi

tujuan dan sasaran bisnis o fungsi bisnis

layanan bisnis o proses bisnis o peran bisnis

model data bisnis

hubungan organisasi dan fungsi

Arsitektur bisnis baseline versi 1.0 (dirinci), jika sesuai

Pandangan yang bersesuaian dengan sudut pandang perhatian stakeholder

kunci
Hasil analisis gap
Kebutuhan

teknismengidentifikasi,

menggolongkan,

dan

memprioritaskan implikasi untuk pekerjaan domain arsitektur lainnya

Laporan arsitektur bisnis
Kebutuhan bisnis yang diperbaharui
4.

Phase C: Information System Architecture

Fase ini membuat arsitektur sistem informasi yang mendukung arsitektur
bisnis. Arsitektur sistem informasi disusun dari arsitektur data dan aplikasi.
Arsitektur data:
Sasaran pada fase ini adalah untuk menetapkan tipe utama dan sumber
data yang penting untuk mendukung bisnis yang dapat dimengerti oleh
stakeholder, lengkap dan konsisten, serta stabil. Penting untuk dicatat bahwa
usaha ini tidak berhubungan dengan rancangan database. Tujuannya adalah
mendefinisikan entitas data yang berhubungan dengan enterprise, bukan untuk
merancang sistem logik atau penyimpanan fisik.
a. Input:
Prinsip data, jika ada
Permintaan untuk pekerjaan arsitektur
Pernyataan pekerjaan arsitektur
b. Visi arsitektur
Kebutuhan teknis yang relevan akan berlaku pada fase C
Hasil analisis gap (dari arsitektur bisnis)
Arsitektur bisnis baseline, versi 1.0 (dirinci), jika sesuai
Arsitektur bisnis target, versi 1.0 (dirinci)
Arsitektur data baseline, Versi 0.1, jika tersedia
Arsitektur data target, versi 0.1, jika tersedia
Building blocks yang dapat digunakan kembali, dari enterprise continuum
organisasi, jika tersedia
c. Langkah-langkah:

 Mengembangkan deskripsi arsitektur data baseline

Me-review dan memvalidasi prinsip, model referensi, sudut pandang, dan
tool
Membuat model arsitektur
Memilih building block arsitektur data
Melakukan review cek formal model arsitektur dan building block dengan
stakeholder
Me-review kriteria kualitatif
Melengkapi arsitektur data
Melakukan cek/analisis dampak
Melakukan analisis gap dan membuat laporan
d. Output:
Pernyataan pekerjaan arsitektur, diperbaharui jika perlu
Arsitektur data baseline versi 1.0, jika sesuai
Prinsip data yang divalidasi, atau prinsip data baru (jika dihasilkan di sini)
Arsitektur data target versi 1.0
Sudut pandang perhatian stakeholder kunci
Pandangan yang berhubungan dengan sudut pandang yang dipilih
Hasil analisis gap
Kebutuhan teknis yang relevan akan berlaku dalam evolusi siklus
pengembangan arsitektur
Laporan arsitektur data
Analisis dampak
Kebutuhan bisnis diperbaharui, jika sesuai
Fase untuk membuat arsitektur aplikasi
Sasaran dalam fase ini adalah menetapkan/mendefinisikan berbagai
jenis sistem aplikasi utama yang diperlukan untuk memproses data dan
mendukung bisnis. Penting untuk dicatat bahwa ini tidak berhubungan
dengan rancangan sistem aplikasi. Tujuannya adalah mendefinisikan jenis
sistem aplikasi yang relevan dengan enterprise dan aplikasi apa yang

dibutuhkan untuk mengelola data dan menghasilkan informasi bagi

pengguna di enterprise.
Aplikasi tidak digambarkan sebagai sistem komputer, tetapi sebagai
kumpulan kapabilitas logik yang mengelola objek data dalam arsitektur
data dan mendukung fungsi bisnis dalam arsitektur bisnis. Aplikasi dan
kapabilitasnya ditetapkan tanpa referensi teknologi tertentu. Aplikasi
adalah stabil dan relatif tidak berubah, sedangkan teknologi yang
digunakan untuk mengimplementasikannya akan berubah dari waktu ke
waktu, berdasarkan pada teknologi yang ada saat ini dan perubahan
kebutuhan bisnis.

5.

Phase D: Technology Architecture

Fase ini membuat arsitektur teknologi yang membentuk fondasi target
infrastruktur TI.
a. Input:
Prinsip teknologi, jika ada
Permintaan untuk pekerjaan arsitektur
Pernyataan pekerjaan arsitektur
b. Visi arsitektur
Arsitektur teknologi baseline, versi 0.1, jika sesuai dan tersedia (dari fase
A)
Arsitektur teknologi target, versi 0.1, jika tersedia (dari fase A)
Kebutuhan teknis yang relevan dari fase sebelumnya
Hasil analisis gap (dari arsitektur data)
Hasil analisis gap (dari arsitektur aplikasi)
Arsitektur bisnis baseline, versi 1.0 (dirinci), jika sesuai
Arsitektur data baseline, versi 1.0, jika sesuai
Arsitektur aplikasi baseline, versi 1.0, jika sesuai
Arsitektur bisnis target, versi 1.0 (dirinci)
Arsitektur data target, versi 1.0

 Arsitektur aplikasi target, versi 1.0

Building blocks yang dapat digunakan kembali, dari enterprise continuum
organisasi, jika tersedia
c. Langkah-langkah:
Mengembangkan deskripsi arsitektur teknologi baseline
Mengembangkan arsitektur teknologi target
d. Output:
Pernyataan pekerjaan arsitektur, diperbaharui jika perlu
Arsitektur teknologi baseline versi 1.0, jika sesuai
Prinsip teknologi yang divalidasi, atau prinsip teknologi baru (jika
dihasilkan di sini)
Laporan arsitektur teknologi
Arsitektur teknologi target versi 1.0
Arsitektur teknologi, laporan analisis gap
Sudut pandang perhatian stakeholder kunci
Pandangan yang berhubungan dengan sudut pandang yang dipilih
Phase B,C, dan D: Developing architecture spesifications
Fase B, C, dan D berkonsentrasi pada pengembangan spesifikasi arsitektur
secara individual yang membentuk arsitektur enterprise keseluruhan. Fasefase ini membuat pandangan EA yang berbeda dari area kepentingan
stakeholder masing-masing.
6.

Phase E: Opportunities and Solutions

Fase E mengidentifikasi parameter perubahan, fase utama sepanjang
tahapan, dan proyek level puncak dilakukan dalam perpindahan dari lingkungan
saat ini ke lingkungan target. Keluaran dari fase E akan membentuk dasar rencana
implementasi yang dibutuhkan. Fase ini juga berusaha untuk mengidentifikasi
kesempatan bisnis baru yang muncul dari pekerjaan arsitektur dalam fase
sebelumnya.
a. Input:
Permintaan untuk pekerjaan arsitektur

 Pernyataan pekerjaan arsitektur

Arsitektur bisnis target, versi 1.0
Arsitektur data target, versi 1.0
Arsitektur aplikasi target, versi 1.0
Arsitektur teknologi target, versi 1.0
Building blocks yang dapat digunakan kembali, dari enterprise continuum
organisasi, jika tersedia
Informasi produk
b. Langkah-langkah:
Mengidentifikasi

driver

bisnis

kunci

yang

menghambat

urutan

implementasi
Me-review analisis gap dari fase D
Brainstorm kebutuhan teknis dari perspektif fungsional
Brainstorm co-existence dan kebutuhan interoperabilitas
Melakukan penilaian arsitektur dan analisis gap
Mengidentifikasi paket pekerjaan atau proyek utama
Klasifikasikan hal tersebut di atas sebagai pengembangan baru,
kesempatan pembelian, atau penggunaan kembali sistem yang ada.
c. Output:
Strategi implementasi dan migrasi
Rencana implementasi tingkat tinggi
Analisis dampakdaftar proyek
7.

Phase F: Migration Planning

Sasaran fase F adalah memilah berbagai proyek implementasi dalam
urutan prioritas. Aktifitasnya meliputi penilaian ketergantungan, biaya, dan
manfaat dari berbagai proyek migrasi. Daftar prioritas proyek akan terus
membentuk basis rencana implementasi dan migrasi yang detil.
a. Input:
Permintaan untuk pekerjaan arsitektur

 Pernyataan pekerjaan arsitektur

Arsitektur bisnis target, versi 1.0
Arsitektur data target, versi 1.0
Arsitektur aplikasi target, versi 1.0
Arsitektur teknologi target, versi 1.0
Analisis dampakdaftar proyek
b. Langkah-langkah:
Memprioritaskan proyek
Memperkirakan kebutuhan dan ketersediaan sumberdaya
Melakukan penilaian biaya/manfaat dari berbagai proyek migrasi
Melakukan penilaian risiko
Membuat roadmap implementasi
Mendokumentasikan rencana migrasi
c. Output:
Analisis dampak: rencana implementasi dan migrasi dirinci (termasuk
kontrak implementasi arsitektur, jika sesuai)
Phase E and F: Developing and planning solutions
Fase E dan F berkaitan dengan penentuan arsitektur solusi spesifik dan
implementasi rencana untuk migrasi dari keadaan arsitektur saat ini ke
keadaan yang baru. Semua keputusan pengadaan rencana pengembangan
dibuat selama dalam fase ini.
8.

Phase G: Implementation Governance (managing deployment and realising

value)
Implementasi tata kelola berada dalam fase G dan memberikan kerangka
tata kelola arsitektur untuk pengembangan solusi dan implementasi. Fase ini
memastikan bahwa pekerjaan pengembangan harus konsisten dengan spesifikasi
arsitektur dan menghasilkan kebutuhan sponsor dan para stakeholder.
a. Input:
Permintaan untuk pekerjaan arsitektur

 Pernyataan pekerjaan arsitektur

Building blocks yang dapat digunakan kembali, dari enterprise continuum
organisasi, jika tersedia
Analisis dampak: rencana implementasi dan migrasi dirinci (termasuk
kontrak implementasi arsitektur, jika sesuai)
b. Langkah-langkah:
Memformulasikan rekomendasi proyek
Mendokumentasikan kontrak arsitektur
Me-review tata kelola implementasi dan pemenuhan arsitektur yang
berkelanjutan
c. Output:
Analisis dampakrekomendasi implementasi
Kontrak arsitektur
Sistem implementasi pemenuhan-arsitektur

9.

Phase H: Architecture Change Management (Managing change)

EA ditetapkan untuk beberapa tahun, tetapi harus juga diperbaharui agar
dapat menyesuaikan perubahan kebutuhan bisnis. Perubahan-perubahan itu bisa
saja diperlukan karena:
Permintaan manajemen aset dan perbaikan infrastruktur;
Peningkatan proses bisnis;
Reorganisasi;
Perubahan pasar dan kapasitas bisnis;
Merger dan akuisisi.
Manajemen perubahan arsitektur, fase terakhir, memungkinkan perubahan
seperti yang disebutkan di atas baik melalui pengembangan maupun siklus
operasional EA.
a. Input:

 Permintaan untuk perubahan arsitektur karena perubahan teknologi

Permintaan untuk perubahan arsitektur karena perubahan bisnis
b. Langkah-langkah:
Memonitor perubahan teknologi
Memonitor perubahan bisnis
Menilai perubahan dan pengembangan posisi untuk bertindak
Mengatur pertemuan Dewan Arsitektur (atau dewan tata kelola yang lain)
Tujuan pertemuan ini adalah untuk memutuskan penanganan perubahan
(teknologi dan bisnis).
c. Output:
Pembaharuan arsitektur
Perubahan pada framework dan prinsip arsitektur
Permintaan baru pekerjaan arsitektur, untuk berpindah ke siklus yang lain
10.

Requirements Management Phase

EA dibuat dari permintaan stakeholder, dikelola di sepanjang metoda ini
dengan proses manajemen kebutuhan. Input pada proses manajemen kebutuhan
adalah output yang berhubungan dengan kebutuhan dari tiap fase ADM.
Kebutuhan tingkat tinggi pertama adalah yang diartikulasikan sebagai bagian dari
visi arsitektur, dihasilkan dengan memakai skenario bisnis atau teknik yang dapat
disamakan. Setiap domain arsitektur menghasilkan kebutuhan rancangan detil
yang dikhususkan untuk domain tersebut dan berpotensi kepada domain lain.
a. Langkah-langkah:
Kebutuhan baseline
Memonitor kebutuhan baseline
Mengidentifikasi kebutuhan yang berubah dan prioritas yang dicatat
b. Output:
Pernyataan kebutuhan yang terstruktur, termasuk:
Kebutuhan yang berubah
Pernyataan dampak kebutuhan

Deliverables, Artefak, dan Building Blocks

Arsitek yang melaksanakan ADM akan menghasilkan sejumlah output
sebagai hasil dari upaya mereka, seperti proses flows, persyaratan arsitektur,
rencana proyek, penilaian kepatuhan proyek, dll. Architecture Content
Framework TOGAF memberikan struktural model untuk konten arsitektur yang
memungkinkan produk kerja utama yang harus konsisten didefinisikan,
terstruktur, dan disajikan.
Architecture Content Framework menggunakan tiga kategori berikut untuk
menggambarkan jenis produk karya arsitektur dalam konteks penggunaan:
1.

Sebuah penyampaian merupakan produk kerja kontrak yang ditentukan secara

resmi diulas, disetujui, dan ditandatangani oleh para pemangku kepentingan.
Kiriman merupakan output dari proyek dan orang-orang kiriman yang ada di
dokumentasi biasanya akan diarsipkan pada penyelesaian proyek, atau dialihkan
menjadi Arsitektur Repository sebagai model referensi, standar, atau snapshot

2.

Architecture Landscape pada titik waktu.

Artefak adalah produk kerja arsitektur lebih rinci yang menggambarkan arsitektur
dari sudut pandang tertentu. Contohnya termasuk diagram jaringan, spesifikasi
server spesifikasi use case, daftar persyaratan arsitektur, dan matriks interaksi
bisnis. Artefak umumnya diklasifikasikan sebagai katalog (daftar), matriks
(menunjukkan hubungan antara hal-hal), dan diagram (gambar). Sebuah
penyampaian arsitektur berisi banyak artefak dan artefak akan membentuk isi

3.

Architecture Repository.
Sebuah blok bangunan merupakan komponen (berpotensi dapat digunakan
kembali) bisnis, IT, atau kemampuan arsitektur yang dapat dikombinasikan
dengan blok bangunan lainnya untuk memberikan arsitektur dan solusi.
Building blocks dapat didefinisikan pada berbagai tingkat detail,
tergantung pada apa tahap perkembangan arsitektur telah tercapai. Misalnya, pada
tahap awal, sebuah blok bangunan dapat hanya terdiri dari nama atau deskripsi
garis. Kemudian, sebuah blok bangunan dapat didekomposisi menjadi beberapa
blok bangunan pendukung dan dapat disertai dengan spesifikasi lengkap. Blok
bangunan dapat berhubungan dengan '' arsitektur '' atau '' solusi ''.

Architecture

Building

Blocks

(ABBs)

biasanya

menggambarkan

kemampuan yang diperlukan dan bentuk spesifikasi Solution Building Blocks

(SBBS). Misalnya kemampuan layanan pelanggan mungkin diperlukan dalam
suatu perusahaan yang didukung oleh banyak SBBS, seperti proses, data, dan
perangkat lunak aplikasi.
Solution Building Block (SBBS) merupakan komponen yang akan
digunakan untuk melaksanakan kemampuan yang diperlukan. Misalnya, jaringan
adalah sebuah blok bangunan yang dapat digambarkan melalui artefak
komplementer dan kemudian dimanfaatkan untuk mewujudkan solusi untuk
perusahaan. Hubungan antara deliverables, artefak, dan building blocks
ditunjukkan pada gambar 2 berikut.

Gambar 2. Hubungan Antara Deliverables, Artefak, dan Building Blocks

Sebagai contoh, sebuah dokumen definisi arsitektur adalah penyampaian

yang mendokumentasikan deskripsi arsitektur. Dokumen ini akan berisi sejumlah
artefak pelengkap yang dilihat dari blok bangunan yang relevan dengan arsitektur.
Sebagai contoh, diagram alir proses (artefak) dapat dibuat untuk menggambarkan
proses penanganan sasaran panggilan (blok bangunan). Artefak ini juga dapat
menjelaskan blok bangunan lainnya, seperti aktor yang terlibat dalam proses
(misalnya, sebuah layanan perwakilan nasabah). Contoh dari hubungan antara
deliverables, artefak, dan building blocks diilustrasikan dalam Gambar 3.

Gambar 3. Contoh Dokumen Definisi Arsitektur

Enterprise Continuum
TOGAF termasuk konsep Enterprise Continuum, yang menetapkan
konteks yang lebih luas untuk seorang arsitek dan menjelaskan bagaimana solusi
generik dapat dimanfaatkan dan khusus untuk mendukung kebutuhan organisasi
individu. Enterprise Continuum adalah gambaran Arsitektur Repository yang
menyediakan metode untuk mengklasifikasikan arsitektur dan solusi artefak.
Enterprise Continuum terdiri dari dua konsep yang saling melengkapi: Continuum
Arsitektur dan Solusi Continuum. Sebuah gambaran dari struktur dan konteks
untuk Enterprise Continuum ditunjukkan pada Gambar 4.

Gambar 4. Enterprise Continuum

Menggunakan TOGAF dengan Framework Lain

Dua elemen kunci dari kerangka arsitektur enterprise adalah:
1.

Definisi kiriman bahwa aktivitas architecting harus menghasilkan

2.

Penjelasan metode yang digunakan ini harus dilakukan

Dengan beberapa pengecualian, sebagian besar framework arsitektur
enterprise fokus pada yang pertama ini - set spesifik dari kiriman - dan relatif
diam tentang metode yang akan digunakan untuk menghasilkan mereka (sengaja
begitu, dalam beberapa kasus). Karena TOGAF adalah framework kerja umum
dan dimaksudkan untuk digunakan dalam berbagai lingkungan, TOGAF
menyediakan framework kerja yang fleksibel dan extensible konten yang
mendukung satu set kiriman arsitektur generik. Akibatnya, TOGAF dapat
digunakan baik

dalam dirinya

sendiri, dengan

kiriman generik

yang

menggambarkan; atau kiriman tersebut dapat diganti atau diperpanjang oleh satu
set yang lebih spesifik, yang didefinisikan dalam suatu framework arsitek
dianggap relevan. Dalam semua kasus, diharapkan arsitek akan beradaptasi dan
membangun framework TOGAF dalam rangka untuk menentukan metode yang
disesuaikan yang terintegrasi ke dalam proses dan struktur organisasi perusahaan.
Menyusun arsitektur ini mungkin termasuk mengadopsi unsur-unsur dari
framework arsitektur lain, atau mengintegrasikan metode TOGAF dengan
framework standar lainnya, seperti ITIL, CMMI, COBIT, PRINCE2, PMBOK,
dan MSP. Sebagai framework umum dan metode untuk arsitektur enterprise,
TOGAF juga melengkapi framework lainnya yang ditujukan khusus domain bisnis
vertikal, khusus bidang teknologi horizontal (seperti keamanan atau pengelolaan),
atau area aplikasi spesifik (seperti e-Commerce).

Daftar Pustaka
Trisyanto Surya, Rendra. 2013. Apa Tata Kelola Teknologi Informasi (IT
Governance) Itu? http://teknologi.kompasiana.com/terapan/2013/09/21/apa-tatakelola-teknologi-informasi-it-governance-itu--591851.html
Henderi dan Sunarya Abas, 2008, Peranan IT Governance Dalam Meningkatkan
Kinerja Organisasi: Permasalahan, Rencana Pengembangan dan Strategi
Penerapan.

CCIT

Journal

2(1),

1-12

https://fanidayantiar.files.wordpress.com/2012/06/vol2no2.pdf
Anonim. 2012. An Introductory Overview of ITIL2011. http://www.bestmanagement-ractice.com/gempdf/itsmf_an_introductory_overview_of_itil_v3.pdf
Gransade,Chris. 2000. The Open Group Architecture Framework (TOGAF).
http://www.togaf.biz/TOGAFWebsitefiles/TOGAF%20-%20presentatie.pdf
Anonim.

2011.

TOGAF

Version

9.

http://www.kingdee.com/news/subject/10togaf/pdf/TOGAF_9_ziyuan.pdf
Anonim.

2011.

An

Overview

of

TOGAF

Version

9.1.

http://www.opengroup.org/public/member/proceedings/q312/togaf_intro_weisma
n.pdf