PERBANDIGAN FRAMEWORK CMMI & TOGAF
Capability
Maturity Model Integration (CMMI) merupakan suatu
model pendekatan dalam penilaian skala kematangan dan kemampuan sebuah
organisasi perangkat lunak. CMMI pada awalnya dikenal sebagai Capability
Maturity Model (CMM) yang dikembangkan oleh Software Enginnering Institute di
Pittsburgh pada tahun 1987. Namun perkembangan selanjutnya CMM menjadi CMMI.
CMMI mendukung proses penilaian secara bertingkat. Penilaiannya tersebut
berdasarkan kuisioner dan dikembangkan secara khusus untuk perangkat lunak yang
juga mendukung peningkatan proses.
CMMI
memiliki 4 aturan yang dapat disesuaikan menurut organisasisoftw are, yakni:
System Engineering(SE), Software Engineering(SW), Integrated Product and
Process Development (IPPD), dan Supplier Sourcing (SS).
CMMI
terdiri dari rangkaian practices. Dalam rangkaian practices ini ada rambu-rambu
atau rekomendasi yang dapat diikuti. Practices dalam CMMI dibagi menjadi dua,
yaitu Generic Practices (GP) dan Specific Practices (SP). Bila kita sudah
mengimplementasikan practices dengan sempurna, kita dianggap sudah memenuhi
Goals. Sama seperti practices, ada Generic Goals (GG) dan Specific Goals (SG).
SG dan SP dikelompokkan menjadi Process Area (PA). Total ada 22 Process Area
dalam CMMI for Development versi 1.2. 22 Process Area tersebut dapat dilihat
dalam gambar di bawah.
Tujuan awal dirumuskannya CMMI sebenarnya adalah untuk mendukung proses
tender di lingkungan Departemen Pertahanan Amerika Serikat (US-DoD). Mereka
ingin memiliki sistem penilaian terhadap semua vendor yang mengajukan proposal.
Untuk itu dirumuskanlah sistem penilaian vendor berupa Maturity Level (ML).
Maturity Level di CMMI ada 5, mulai dari yang terendah ML 1, sampai yang
paling canggih ML 5. Bila suatu perusahaan sudah ML-5, maka perusahaan tersebut
bisa ikut dalam tender proyek.
Setiap ML memiliki seperangkat PA yang harus dipenuhi agar kita berhak
menggunakan titel ML tersebut. Sebagai contoh, bila suatu perusahaan ingin
lulus ML-2, maka perusahaan tersebut harus mengimplementasikan 7 PA. Untuk
mencapai ML-3, perusahaan harus mengimplementasikan 7 PA dari ML-2 ditambah
dengan 11 PA dari ML-3. Demikian seterusnya, sehingga ML-5 yang sudah
mengimplementasikan 22 PA. Bila suatu perusahaan sama sekali belum
mengimplementasikan apa-apa, perusahaan tersebut dikategorikan sebagai ML-1.
Beberapa
kegunaan CMMI, yaitu :
·
Untuk mengukur tingkat
kematangan dari suatu perusahaan atau organisasi pengembang perangkat lunak.
· Sebagai alat bantu sebagai alat uji-kinerja atau benchmarking dengan perusahaan atau organisasi
lain.
· Pemberi arah untuk top management untuk meningkatkan kinerja pada sebuah
perusahaan/organisasi pengembang software.
· Meminimalisir adanya resiko dalam pembangunan sebuah software.
· Implementasi CMMI yang tepat d meningkatkan kinerja organisasi dari sisi
biaya, waktu, mutu, kepuasan pelanggan dan return on investment (ROI).
Model
CMMI dipecah menjadi lima tingkatan. Tujuan CMMI adalah untuk meningkatkan
organisasi hingga Level 5, level kematangan yang "mengoptimalkan".
Lima
Tingkat CMMI adalah:
1. Initial
Proses dianggap tidak dapat
diprediksi dan reaktif. Pada tahap ini, "pekerjaan diselesaikan tetapi
sering kali ditunda dan melebihi anggaran." Ini adalah tahap terburuk yang
dapat ditemukan oleh bisnis - lingkungan yang tidak terduga yang meningkatkan
risiko dan inefisiensi.
Dan
pada level ini memiliki beberapa ciri khas seperti berikut ini:
· Tidak
adanya manajemen proyek.
· Tidak
adanya quality assurance.
· Tidak
ada dokumentasi.
· Sangat
bergantung pada kemampuan individual.
2. Managed
Ada tingkat manajemen
proyek yang dicapai. Proyek “direncanakan, dilakukan, diukur dan dikendalikan”
pada tingkat ini, tetapi masih ada banyak masalah yang harus diatasi. Dan repeatable ini memiliki ciri sebagai berikut:
·
Kualitas software mulai
bergantung pada proses bukan pada sumber dayanya.
·
Ada manajemen proyek
sederhana.
·
Ada quality assurance
sederhana.
·
Ada dokumentasi sederhana.
·
Ada software configuration
manajemen sederhana.
·
Tidak ada komitmen untuk
selalu mengikuti SDLC dalam kondisi apapun.
·
Rentan terhadap perubahan
struktur organisasi.
3. Defined
Pada tahap ini,
organisasi lebih proaktif daripada reaktif. Ada satu set "standar
organisasi" untuk "memberikan panduan lintas proyek, program, dan
portofolio." Bisnis memahami kekurangan mereka, bagaimana cara
mengatasinya dan apa tujuan perbaikan. Dan pada
proses ini memiliki ciri sebagai berikut:
· SDLC
(System Development Life Cycle) sudah dibuat dan dibakukan.
· Ada
komitmen untuk mengikuti SDLC dalam keadaan apapun.
· Kualitas
proses dan produk masih sebatas hanya kira-kira saja.
· Tidak
menerapkan Activity Based Costing.
4. Quantitatively
Managed
Tahap ini lebih terukur
dan terkontrol. Rumah sakit sedang mengerjakan data kuantitatif untuk
menentukan proses yang dapat diprediksi yang selaras dengan kebutuhan pemangku
kepentingan. Bisnis berada di depan risiko, dengan lebih banyak data yang
didorong wawasan tentang kekurangan proses. Pada level ini memiliki beberapa
ciri sebagai berikut :
· Sudah
adanya Activity Based Costing dan digunakan untuk mengestimasikan untuk proyek
berikutnya.
· Proses
penilaian kualitas perangkat lunak dan proyek bersifat kuantitatif.
· Terjadi
pemborosan biaya untuk pengumpulan data karena proses pengumpulan data masih
dilaukan secara manual.
5. Optimizing
Di sini, proses
organisasi stabil dan fleksibel. Pada tahap akhir ini, sebuah organisasi akan
terus-menerus meningkatkan dan merespons perubahan atau peluang lainnya.
Organisasi ini stabil, yang memungkinkan lebih banyak "kelincahan dan
inovasi," dalam lingkungan yang dapat diprediksi. Ciri dari level terakhir
ini adalah sebagai berikut:
· Pengumpulan
data sudah dilakukan secara secara otomatis.
· Adanya
mekanisme feedback yang sangat baik.
· Adanya
peningkatan kualitas dari SDM dan peningkatan kualitas proses.
Beberapa
aturan yang terdapat pada CMMI, yaitu :
· Pernyataan kebutuhan user harus dicatat
·
Pernyataan kebutuhan harus
dikonfirmasi ke user
·
Pernyataan kebutuhan harus disetujui
kedua pihak
·
Kalau ada perubahan, harus
dicatat
·
Antara kebutuhan dan
software yang dideliver, harus bisa dilacak bolak-balik
TOGAF atau The Open Group Architecture
Framework adalah
suatu kerangka kerja arsitektur perusahaan yang memberian pendekatan
komprehensif untuk desain, perencanaan, implementasi, dan tata kelola
arsitektur informasi perusahaan. Arsitektur ini biasanya dimodelkan dengan
empat tingkat atau domain; bisnis, aplikasi, data, dan teknologi.
The Open Group Architecture Framework (TOGAF) adalah sebuah framework yang
dikembangkan oleh The Open Group’s Architecture Framework pada
tahun 1995. Awalnya TOGAF digunakan oleh Departemen Pertahanan Amerika Serikat
namun pada perkembangannya TOGAF banyak digunakan pada berbagai bidang seperti
perbankan, industri manufaktur dan juga pendidikan. TOGAF ini digunakan untuk
mengembangkan enterprise architecture, dimana terdapat metode dan
tools yang detil untuk mengimplementasikannya, hal inilah yang membedakan
dengan framework EA lain misalnya framework Zachman. Salah satu kelebihan
menggunakan framework TOGAF ini adalah karena sifatnya yang fleksibel dan
bersifat open source.
TOGAF memandang enterprise architecture ke dalam empat
kategori, yaitu:
- Business
Architecture: Mendeskripsikan tentang bagaimana proses
bisnis untuk mencapai tujuan organisasi.
- Application
Architecture: Merupakan pendeskripsian bagaimana aplikasi
tertentu didesain dan bagaimana interaksinya dengan apikasi lainnya.
- Data Architecture: Adalah penggambaran bagaimana penyimpanan,
pengelolaan dan pengaksesan data pada perusahaan.
- Technical
Architecture : Gambaran mengenai infastruktur hardware dan software yang
mendukung aplikasi dan bagaimana interaksinya.
TOGAF secara umum memiliki struktur dan komponen sebagai berikut:
- Architecture
Development Method (ADM) :
Merupakan bagian utama dari TOGAF yang memberikan gambaran rinci bagaimana
menentukan sebuah enterprise architecture secara spesifik berdasarkan
kebutuhan bisnisnya.
- Foundation
Architecture (Enterprise Continuum) :
Foundation Architecture merupakan sebuah “framework-within-a-framework”
dimana didalamnya tersedia gambaran hubungan untuk pengumpulan arsitektur
yang relevan, juga menyediakan bantuan petunjuk pada saat terjadinya
perpindahan abstraksi level yang berbeda. Foundation Architecture dapat
dikumpulkan melalui ADM. Terdapat tiga bagian pada foundation architecture
yaitu Technical Reference Model, Standard Information dan Building Block
Information Base.
- Resource
Base: Pada bagian ini
terdapat informasi mengenai guidelines, templates, checklists,latar belakang
informasi dan detil material pendukung yang membantu arsitek didalam
penggunaan ADM.
Architecture Development Method (ADM) merupakan metodologi lojik dari TOGAF yang
terdiri dari delapan fase utama untuk pengembangan dan pemeliharaan technical
architecture dari organisasi. ADM membentuk sebuah siklus yang iteratif untuk
keseluruhan proses, antar fase, dan dalam tiap fase di mana pada tiap-tiap
iterasi keputusan baru harus diambil.
Keputusan tersebut dimaksudkan untuk menentukan
luas cakupan enterprise, level kerincian, target waktu yang ingin dicapai dan
asset arsitektural yang akan digali dalam enterprise continuum. ADM merupakan
metode yang umum sehingga jika diperlukan pada prakteknya ADM dapat disesuaikan
dengan kebutuhan spesifik tertentu, misalnya digabungkan dengan framework yang
lain sehingga ADM menghasilkan arsitektur yang spesifik terhadap organisasi.
ADM dapat dikenali dengan penggambaran siklus yang
terdiri dari delapan langkah proses, yaitu :
- Architecture
Vision
- Business
Architecture
- Information
System Architecture
- Technology
Architecture
- Opportunities
and Solution
- Migration
Planning
- Implementation
Governance
- Architecture
Change Management.
TOGAF ADM juga merupakan metode yang bersifat
generik dan mudah di terapkan berdasarkan kebutuhan banyak organisasi, baik
organisasi industri ataupun industri akademik seperti perguruan tinggi.
Secara singkat kedelapan fase ADM adalah sebagai berikut:
- Fase
Preliminary: Framework and Principles: Merupakan fase persiapan yang bertujuan
untuk mengkonfirmasi komitmen dari stakeholder, penentuan framework dan
metodologi detil yang akan digunakan pada pengembangan EA.
- Fase A : Architecture Vision. Fase ini memiliki tujuan untuk memperoleh
komitmen manajemen terhadap fase ADM ini,
memvalidasi prinsip, tujuan dan pendorong bisnis, mengidentifikasi
stakeholder. Terdapat beberapa langkah untuk mencapaian tujuan fase ini
dengan inputan berupa permintaan untuk pembuatan
arsitektur, prinsip arsitektur dan enterprise continuum. Output dari fase
ini adalah: (1) pernyataan persetujuan pengerjaan arsitektur yang
meliputi: Scope dan konstrain serta rencana pengerjaan arsitektur, (2)
prinsip arsitektur termasuk prinsip bisnis, (3) Architecture
Vision.
- Fase B : Business Architecture. Fase B bertujuan
untuk (1) memilih sudut pandang terhadap arsitektur yang bersesuaian
dengan bisnis dan memilih teknik dan tools yang
tepat (2) mendeskripsikan arsitektur bisnis eksisting dan target
pengembangannya serta analisis gap antara keduanya. Inputan untuk fase B
berasal dari output fase A, sedangkan outputnya adalah revisi terbaru dari
hasil ouput fase A ditambah dengan arsitektur bisnis eksisting dan target
pengembangannya secara detil serta hasil analisis gap, business
architecture report dan kebutuhan bisnis yang telah diperbaharui.
- Fase
C : Information Systems Architectures. Tujuan fase ini adalah untuk mengembangkan
arsitektur target untuk data dan/atau domain aplikasi. Pada arsitektur
data misalkan untuk menentukan tipe dan sumber data yang diperlukan untuk
mendukung bisnis dengan cara yang dimengerti oleh stakeholder. Pada
arsitektur aplikasi untuk menentukan jenis sistem aplikasi yang dibutuhkan
untuk memproses data dan mendukung bisnis.
- Fase
D : Technology Architecture.
Untuk pengembangan arsitektur teknologi target yang akan menjadi basis
implementasi selanjutnya.
- Fase
E : Opportunities and Solutions. Secara umum merupakan fase untuk
mengevaluasi dan memilih cara pengimplemetasian, mengidentifikasi
parameter strategis untuk perubahan, perhitungan cost dan benefit dari
proyek serta menghasilkan rencana implementasi secara keseluruhan berikut
strategi migrasinya.
- Fase
F : Migration Planning:
Fase ini bertujuan untuk mengurutkan implementasi proyek berdasarkan
prioritas dan daftar tersebut akan menjadi basis bagi rencana detil
implementasi dan migrasi.
- Fase
G : Implementation Governance. Merupakan tahapan memformulasikan
rekomendasi untuk setiap implementasi proyek, membuat kontrak arsitektur
yang akan menjadi acuan implementasi proyek serta menjaga kesesuaiannya
dengan arsitektur yang telah ditentukan.
- Fase
H : Architecture Change Management. Pada akhir fase ini diharapkan terbentuk
skema proses manajemen perubahan arsitektur.
- Requirements
Management, bertujuan untuk
menyediakan proses pengelolaan kebutuhan arsitektur sepanjang fase pada
siklus ADM, mengidentifikasi kebutuhan enterprise, menyimpan lalu
memberikannya kepada fase yang relevan.
|
|
Berikut ini perbandingan berupa beberapa perbedaan
antara CMMI (Capability
Maturity Model Integration) dengan TOGAF (The
Open Group Architecture Framework), yaitu :
1. TOGAF adalah suatu kerangka kerja arsitektur perusahaan
yang memberian pendekatan komprehensif untuk desain, perencanaan, implementasi,
dan tata kelola arsitektur informasi perusahaan. Arsitektur ini biasanya
dimodelkan dengan empat tingkat atau domain; bisnis, aplikasi, data, dan
teknologi. Sedangkan, CMMI merupakan suatu model pendekatan dalam penilaian skala
kematangan dan kemampuan sebuah organisasi perangkat lunak.
2. TOGAF digunakan agar agar dapat
memperbaiki atau meningkatkan arsitektur suatu perusahaan. Sedangkan CMMI
digunakan untuk mengukur tingkat kematangan suatu perusahaan yang nantinya
berguna sebagai bentuk kesiapan dalam bersaing dengan perusahan lainnya.
3.
TOGAF memiliki kerangka penting ADM (Architecture
Development Method). ADM adalah resep untuk menciptakan
arsitektur. Sedangkan CMMI
tidak memiliki kerangka membangun, melainkan rangkaian practices kita dianggap
sudah memenuhi Goals.
4.
TOGAF lebih memfokuskan perencanaan perusahaan, fokus pada hal hal internal
perusahaan. Sedangkan CMMI tidak hanya fokus pada internal, namun pada kepuasan
pelanggan atau konsumen.
5.
TOGAF berfokus pada perancangan dan penyelarasan hardware dan software untuk
mendukung perusahaan. CMMI berfokus meningkatkan.
6.
TOGAF memiliki Sertifikasi yang berfungsi untuk menjamin bahwa orang atau
lembaga telah mampu memahami dan menerapkan konsep dalam TOGAF. Sedangkan dalam
CMMI tidak mengenal istilah sertifikasi, yang ada hanyalah penilaian
(appraisal) suatu perusahaan sudah mencapai tingkat maturity/capability level
berapa.
PENUTUP
Agar pengelolaan perusahaan dapat berjalan dengan baik maka perusahaan
perlu menggunakan suatu Framework IT Berdasarkan dari penjelasan di atas dapat disimpulkan
bahwa CMMI dan TOGAF memiliki peranan yang berbeda sebagai framework
audit IT. CMMI sebagai framework yang menyediakan untuk memberikan
penilaian terhadap keberhasilan kinerja atau kualitas dari suatu organisasi
perangkat lunak serta mengetahui
perubahan-perubahan apa yang harus dilakukan guna meningkatkan organisasi atau
perusahaan tersebut. Sedangkan TOGAF sebagai framework yang mendukung dalam pengembangan
suatu arsitektur perusahaan dengan mendesain,
merencanakan tata kelola arsitektur informasi perusahaan.
CMMI merupakan suatu model pendekatan dalam
penilaian skala kematangan dan kemampuan sebuah organisasi perangkat lunak. TOGAF merupakkan
suatu kerangka kerja arsitektur perusahaan yang memberian pendekatan
komprehensif untuk desain, perencanaan, implementasi, dan tata kelola
arsitektur informasi perusahaan. CMMI dan TOGAF memiliki
peranan yang berbeda sebagai framework audit IT. CMMI sebagai framework yang
menyediakan untuk memberikan penilaian terhadap kualitas dari suatu organisasi
perangkat lunak sedangkan TOGAF sebagai framework yang mendukung dalam
pengembangan suatu arsitektur perusahaan. CMMI dan TOGAF mempunyai keuntungan
masing-masing yang dapat disesuaikan oleh Kebutuhan perusahaan.
Komentar
Posting Komentar