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.

B. Tujuan Maturity Level

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.

C. Kegunaan CMMI

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

D. Tingkat Kematangan CMMI

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.

E. Aturan Dalam CMMI

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

II. The Open Group Architecture Framework (TOGAF)

A. Pengertian TOGAF (The Open Group Architecture Framework)

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.

B. Domain enterprise architecture

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.

C. Struktur dan Komponen TOGAF

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.

D. Architecture Development Method (ADM) pada TOGAF

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.

III. Perbandingan Capability Maturity Model Integration (CMMI) dengan The Open Group Architecture Framework (TOGAF)

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

KESIMPULAN

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.