ABSTRAK
Kegagalan dalam mengorganisir kompleksitas IT yakni argumentasi terbesar yang membuat metode IT sering gagal. Dan ketika kompleksitas mulai terasa, kegagalan menjadi peristiwa, mahal, dan biasanya sungguh menonjol . Contoh kegagalan yang disebabkan alasannya adalah kompleksitas meresap di sektor publik dan swasta, merugikan ongkos dengan rentang nilai mulai dari puluhan ribu hingga miliaran dolar.Pendekatan Partisi Iteratif sungguh-sungguh terfokus pada pengendalian kompleksitas arsitektur enterprise. partisi digunakan untuk secara dramatis meminimalkan kompleksitas keseluruhan, sering dengan beberapa kali lipat. Arsitektur enterprise divalidasi melalui proses terkendali prioritas dan iterasi. Pendekatan partisi iteratif adalah meningkatkan tingkat keberhasilan keseluruhan proyek. Dan mampu memampatkan waktu jauh lebih banyak. Hal ini sebab desain tiap partisi hanya membutuhkan staf yang secara langsung terlibat dalam partisi. Framework yang ada dikala ini sudah mulai mengimplementasikan pendekatan partisi iterative. Contoh framework yang menggunakan pendekatan ini adalah SIP (Simple Iterative Partitions).
1. Pengenalan
1.1 Latar Belakang
(Sessions, 2007) Hampir segala sesuatu dalam organisasi besar mampu menjadi lebih kompleks. Di segi bisnis, standar dan peraturan, kekerabatan kemitraan, merger, dan akuisisi semua membuat proses bisnis menjadi lebih kompleks. Di segi teknologi, versi distribusi gres, permintaan interoperabilitas tinggi, dan otomatisasi alur kerja menimbulkan metode IT lebih kompleks.
Hal ini menjadi sebuah tantangan untuk membangun tata cara IT yang sungguh kompleks, memutuskan bahwa tata cara tersebut menyanggupi kebutuhan proses bisnis yang kian kompleks, dan melakukannya dengan cara yang memungkinkan segala sesuatu beradaptasi dengan segera terhadap perubahan keadaan pasar.
Kegagalan dalam mengurus kompleksitas IT adalah argumentasi terbesar yang menciptakan metode IT sering gagal. Dan ketika kompleksitas mulai terasa, kegagalan menjadi tragedi, mahal, dan lazimnya sangat mencolok. Contoh kegagalan yang disebabkan karena kompleksitas meresap di sektor publik dan swasta, merugikan biaya dengan rentang nilai mulai dari puluhan ribu hingga miliaran dolar.
Untuk mengetahui kegagalan banyak sekali metodologi arsitektur enterprise, kita perlu memahami karakteristik apa saja yang menjadikan semua usaha tersebut gagal dalam menciptakan arsitektur enterprise. Hanya ada satu karakteristik yang dimiliki oleh tata cara metode tersebut, ialah kompleksitas. Semua metode ini sungguh kompleks. Kelemahan utama FEAF, TOGAF, dan Zachman adalah kegagalan mereka untuk mengurus kompleksitas tata cara. (Sessions, 2006)
Menyusun kompleksitas yang ada dan menyajikannya dalam bentuk yang gampang dipahami, sudah lama dipakai oleh para perancang bangunan dalam menghidangkan desain bangunan yang mereka ajukan. Disiplin arsitektural ini lalu berkembang menjadi satu disiplin yang menandai pertumbuhan peradaban insan dikala ini.
(Sadat, 2007) Perkembangan yang cepat dalam teknologi isu, juga telah memajukan tingkat kompleksitas penggunaan teknologi informasi. Meningkatnya kompleksitas ini menuntut upaya lebih bagi para pengembang teknologi untuk menghidangkan penjelasan sederhana atas penggunaan teknologi bagi kalangan lainnya. Penjelasan sederhana tersebut sering diketahui selaku arsitektur teknologi berita. Sayangnya, ragam gaya penyajian arsitektur lalu mengaburkan pengertian arsitektur teknologi.
1.2 Tujuan
Paper ini menjelaskan bagaimana kompleksitas arsitektur enterprise IT sejalan dengan bertambah besarnya enterprise itu sendiri. Beberapa penyelesaian dirangkum untuk memudahkan pengertian ihwal mempersempit atau mengontrol kompleksitas itu. Kontribusi paper ini adalah untuk mendeskripsikan citra ihwal Arsitektur Enterprise dan penggunaan partisi iterative dalam penyederhanaan kompleksitas Arsitektur Enterprise.
2. Kompleksitas Arsitektur Enterprise
2.1 Definisi Arsitektur Enterprise
(Sessions, 2006) Arsitektur enterprise ialah sebuah deskripsi dari tujuan organisasi, bagaimana tujuan-tujuan ini direalisasikan oleh proses bisnis, dan bagaimana proses bisnis dapat berjalan lebih baik dengan teknologi. Arsitektur enterprise memperlihatkan strategi yang memungkinkan organisasi mendukung adanya keadaan yang kini dan juga bertindak sebaga roadmap menuju lingkungan yang ditargetkan.
Sebuah Arsitektur enterprise berfungsi mengkolaborasikan perencanaan strategis perusahaan dan penyusunan rencana kinerja dengan enterprise data architecture, enterprise application architecture, dan enterprise technical architecture (Hendley, 2008). Arsitektur enterprise merupakan suatu fungsi bisnis yang berkelanjutan yang menolong ‘enterprise’ mencari cara untuk mengeksekusi mana strategi yang terbaik yang mendorong perkembangannya.
Dalam menyebarkan arsitektur enterprise, terdapat beberapa alat bantu yang dikenal sebagai architecture framework. Architecture framework memiliki model simbolis untuk menspesifikasikan banyak sekali fase arsitektur enterprise. Dari suatu versi simbolis diinterpresentasikan makna dari dari masing-masing simbol pada sebuah model. korelasi antara model semantik dengan arsitektur dapat dimengerti dengan mengerti tujuan dari modeling apalagi dulu untuk memprediksi realitas dari keadaan yang bergotong-royong. Didalam sebuah arsitektur enterprise mesti terdapat suatu tutorial persyaratan, kebijakan dan hukum-aturan bisnis yang menggambarkan lingkungan perusahaan.
Beberapa architecture framework yang dikenal antara lain: Zachman Framework, Enterprise Architecture Planning (EAP), The Federal Enterprise Architecture Framework (FEAF), OMG Model Driven Architecture (MDA), The Open Group Architecture Framework (TOGAF).
2.2 Kasus Kompleksitas Arsitektur Enterprise
2.2.1 Sektor Publik
(Sessions, 2006) FBI sudah di kritik berat untuk menyia-nyiakan lebih dari 500 juta USD alasannya gagal dalam menciptakan sebuah virtual case-filing system. FEMA menghabiskan lebih dari 100 juta USD untuk suatu metode yang terbukti tidak efektif menangani Badai Katrina. Kelompok Federal yang lain yang sudah menjadi subyek kritik GAO tergolong Biro Sensus, Badan Penerbangan Federal, Penerbangan dan Antariksa Nasional, HUD, Kesehatan dan Layanan Manusia, Medicare, dan MedicAid.
Pemerintah AS berlangsung tidak terlampau baik. Hampir satu bulan berlalu di mana Government Accountability Office (GAO), cabang pengawas independen dari Pemerintah AS, tidak mengeluarkan laporan pedas pada praktek Teknologi Informasi dari setidaknya satu forum. Tampaknya bahwa kian penting lembaga pemerintah, makin besar kemungkinan mempunyai kegagalan dalam IT.
(Sessions, 2006) FBI sudah di kritik berat untuk menyia-nyiakan lebih dari 500 juta USD karena gagal dalam membuat sebuah virtual case-filing system. FEMA menghabiskan lebih dari 100 juta USD untuk suatu metode yang terbukti tidak efektif menangani Badai Katrina. Kelompok Federal yang lain yang sudah menjadi subyek kritik GAO tergolong Biro Sensus, Badan Penerbangan Federal, Penerbangan dan Antariksa Nasional, HUD, Kesehatan dan Layanan Manusia, Medicare, dan MedicAid.
2.2.2 Sektor Swasta
Meskipun kegagalan industri swasta jarang menjadi isu utama, sektor swasta juga kadang kala ceroboh dalam hal TI skala besar. Kegagalan ini tampaknya sebagian besar disebabkan alasannya kegagalan dalam metodologi arsitektur enterprise, contohnya:
- Upaya McDonald gagal dalam membangun sebuah sistem administrasi bisnis yang terintegrasi yang hendak menyatukan seluruh bisnis kedai makanan mereka. Biaya: $ 170 juta. (Barrett & Gallagher, 2003)
- Upaya Ford gagal dalam membangun metode pembelian yang terintegrasi. Biaya: $ 400 juta. (Keefe, 2004)
- Upaya KMart gagal dalam membangun sistem manajemen rantai pasok level tinggi. Biaya: $ 130 juta. (Carr & Cone, 2001)
2.3. Memodelkan Kompleksitas Arsitektur Enterprise
Mengapa kita membutuhkan model untuk suatu kompleksitas? Sebagai analogi, bayangkan peluncuran ke bulan. Sebuah peluncuran ke bulan adalah usaha yang sangat kompleks. Misalkan kita tidak mempunyai model untuk gravitasi dan gerakan planet. Tanpa model mirip itu, setiap keputusan wacana peluncuran ke bulan, dari jumlah materi bakar, kekuatan dorong, hingga sudut peluncuran hanya didasarkan pada insting, tebakan hasil pengalaman, dan intuisi baku. Berapa banyak peluncuran bulan tersebut yang mungkin berhasil? (Sessions, 2007).
Untuk memodelkan kompleksitas arsitektur enterprise pertama-tama kita harus memahaminya terlebih dahulu. Kita misalkan kompleksitas yakni sebuah dadu. Model ini memiliki keuntungan intuitif, visual, prediksi, dan matematis. Semisal perbandingan kompleksitas dua metode yakni, Sistem A dan Sistem B, seperti yang ditunjukkan pada Gambar-1. Suatu tata cara berisikan dua segi (yaitu, koin), sedangkan Sistem B terdiri dari enam segi dadu (yaitu, dadu kriteria).
Sistem A hanya mempunyai dua sisi memiliki peluang: kepala dan angka. Sistem B memiliki enam segi potensial: 1, 2, 3, 4, 5, dan 6. Berdasarkan perkiraan matematis, Sistem B yaitu 6/2, atau 3 kali lebih kompleks daripada A. Secara lazim, jumlah state dari sistem dimana D adalah dadu, dan S yakni segi, yaitu Sekolah Dasar. Dengan rumus ini, kita mampu menghitung kompleksitas metode lainnya.
Sekarang, mari kita bandingkan Sistem B dan C. Sistem B terdiri dari satu dadu bersisi enam sisi, seperti sebelumnya, dan Sistem C terdiri dari tiga dadu dengan masing-masing enam sisi, mirip yang ditunjukkan pada Gambar 2.
Jumlah state B masih 61, atau 6. Jumlah state C adalah 63, atau 216. Sistem C yakni 216/6, atau 36 kali lebih kompleks dibandingkan Sistem B. Jika Anda akan memprediksi hasil tertentu dengan melempar dadu di Sistem C, Anda akan memiliki satu kesempatan dibanding 216 untuk menerima suatu kebenaran. Jika Anda memprediksi hasil tertentu dengan melemparkan dadu dalam Sistem B, maka Anda akan mempunyai potensi 1 : 6 untuk menerima karenanya. Jika Anda akan menciptakan tebakan berulang untuk kedua metode, Anda akan benar 36 kali lebih sering dengan Sistem B daripada dengan Sistem C. Karena Sistem B lebih sederhana ketimbang Sistem C, dan lebih mudah untuk diprediksi.
3. Penyederhanaan Arsitektur Enterprise
3.1. Solusi untuk kompleksitas
Beberapa latar belakang dalam teori dan praktek dalam pendekatan partisi iterasi untuk arsitektur enterprise, yang menunjukkan seperangkat hukum supaya mampu membantu Anda lebih berhasil dengan pendekatan ini.
Untuk menyederhanakan kompleksitas arsitektur enterprise mampu menggunakan pendekatan partisi iteratif. partisi digunakan untuk secara dramatis meminimalkan kompleksitas keseluruhan, sering dengan beberapa kali lipat. Arsitektur enterprise divalidasi melalui proses terkendali prioritas dan iterasi.
3.2. Partisi
Dengan versi kompleksitas dasar, kita mampu menerima gambaran bagaimana sistem yang kompleks mampu lebih terorganisir. Sebagai pola, kita bandingkan dua tata cara, Sistem C dan D Sistem, keduanya terdiri dari tiga dadu bersisi enam. Dalam Sistem C, semua dadu bantu-membantu, seperti sebelumnya. Dalam Sistem D, dadu dibagi menjadi tiga partisi. Dua sistem ini ditunjukkan pada Gambar 3.
Diasumsikan bahwa kita mampu bermasalah dengan tiga partisi mampu berdiri diatas kaki sendiri, tiga subsistem, masing-masing mirip Sistem B. Kompleksitas keseluruhan Sistem D dapat diartikan sebagai kompleksitas dari partisi pertama, ditambah kompleksitas partisi kedua, ditambah kompleksitas partisi ketiga. Kompleksitas dari setiap partisi masih diberikan oleh aturan SD, ialah 61, atau 6. Kompleksitas Sistem D seluruhnya 6 +6 +6, atau 18.
Secara umum, kompleksitas metode dimana P adalah partisi, dan masing-masing dengan kompleksitas C, yaitu C x P. Jika setiap partisi berisi satu dadu, maka rumus ini menjadi S1 x D, yang disederhanakan menjadi S x D. Untuk menyederhanakan ini, kita mengasumsikan bahwa setiap partisi hanya berisi satu dadu (seperti yang dikerjakan Sistem D). Maka, kompleksitas dari sistem non-partisi (misalnya, Sistem C) senantiasa Sekolah Dasar, dan kompleksitas dari metode partisi (contohnya, Sistem D) selalu S x D.
Bagaimana dua rumus (S x D) dan (SD) dibandingkan satu sama lain. Tabel 1 memperlihatkan nilai yang berlawanan untuk S, D, rumus partisi (S x D), dan formula non-partisi (Sekolah Dasar).
3.3 Iteratif
Setelah kita menggunakan partisi untuk meminimalkan kompleksitas, dibuatlah keputusan lain. Bagaimana kita menganalisis kompleksitas yang tersisa? Ada dua pilihan: iteratif (kiri ke kanan) atau rekursif(atas-ke-bawah). Anda dapat melihat perbedaan kedua pendekatan dengan melihat lagi di model kompleksitas partisi dadu, mirip yang ditunjukkan pada Gambar-4.
Dalam pendekatan kompleksitas iteratif, kita menganalisis partisi masing-masing individu. Misalnya, pertama-tama kita menganalisis Partisi 1. Kemudian, menganalisis Partisi 2 dan terus hingga setiap partisi dianalisis. Pendekatan kompleksitas rekursif menganalisis lapisan horizontal setiap partisi. Misalnya, pertama-tama menganalisis perkara di mana semua dadu berada. Analisis ini dilanjutkan hingga dengan menyelesaikan perkara terakhir yang memungkinkan untuk semua partisi. Namun, Dalam menganalisis kompleksitas, iterasi cepat hampir senantiasa menghasilkan hasil yang lebih baik daripada analisis mendalam. (Sessions, 2006)
3.4 Partisi Iteratif
Sekarang kita mempunyai dua pelajaran tentang bagaimana mengelola kompleksitas arsitektur enterprise. Dari studi dadu, kita mampu mengetahui bahwa kompleksitas partisi yakni salah satu kunci untuk meminimalisir kompleksitas. Dan dalam menganalisis kompleksitas, iterasi cepat hampir senantiasa menciptakan hasil yang lebih baik ketimbang analisis mendalam
Kita mampu berasumsi bahwa teladan sebelumnya kegagalan arsitektur (misalnya, kegagalan dalam Kasus FBI Virtual File System atau manajemen bisnis McDonald) seluruhnya didasarkan pada metodologi arsitektur enterprise persyaratan mirip FEAP, TOGAF, dan Zachman. Metodologi ini semua non-iteratif. Hal ini tak mengherankan, alasannya adalah itu, bahwa mereka semua gagal. Ini juga tidak mengherankan bahwa kegagalan mereka yang begitu mahal. Tahap-tahap berikut harus ada dalam Metodologi arsitektur enterprise :
Metodologi tradisional mengambilnya selaku satu fase pada suatu waktu, lalu menyelesaikan satu secara keseluruhan sebelum yang selanjutnya dimulai. Hal ini ditunjukkan pada Gambar-5.
Gambar 6. Partisi iterasi
Hasil dari pendekatan partisi iteratif ialah pedoman konstan yang keluar dari fungsionalitas. Sebuah partisi tidak akan dilaksanakan sebelum partisi sebelumnya selesai. Dalam organisasi yang kompleks dan besar, jarang terdapat proyek simultan secara paralel, namun jumlahnya mesti dijaga seminim mungkin, terutama di iterasi permulaan. Beberapa proyek yang bersamaan akan memajukan keperluan untuk koordinasi.
3.5 Implementasi Pendekatan Partisi Iteratif
(Sessions, 2006) Keuntungan dari implementasi pendekatan partisi iteratif yaitu memajukan tingkat keberhasilan keseluruhan proyek. Hal ini dikarenakan penerapan iterasi sebelumnya dapat menjadi pelajaran untuk iterasi selanjutnya.
Semisal teridentifikasi problem dalam akurasi waktu yang dibutuhkan untuk melatih para developer. Ketika menangani antarmuka call center, sudah harus mampu ditentukan penetapan pengembang mana yang berpengalaman. Jika tool pengembangan lebih rumit ketimbang yang dijadwalkan, maka dapat dipertimbangkan tool lainnya. Jika proses memakan waktu lebih usang dari rencana, jadwal sudah mampu disesuaikan dengan waktu yang tersisa.
Titik penting yaitu dengan iterasi dipartisi dapat ditemukan masalah awal, sebelum mereka menghancurkan seluruh proyek. Dan, bila mereka tidak mampu diperbaiki, setidaknya mereka dapat diketahui sebelum penundaan yang mengagetkan manajemen. Keuntungan lain dari iterasi dipartisi adalah dapat memampatkan waktu jauh lebih banyak. Hal ini sebab desain tiap partisi hanya membutuhkan staf yang secara pribadi terlibat dalam partisi.
Sebuah metodologi arsitektur enterprise yang didasarkan pada versi matematika untuk kompleksitas IT yang disebut Simple Iterative Partitions (SIP). Model ini didasarkan pada teori probabilitas dan teori himpunan. Model ini memprediksi kompleksitas IT seperti fisika memprediksi gaya gravitasi. Dengan cara yang serupa, ilmuwan NASA mampu memakai model gravitasi untuk memprediksi konsumsi bahan bakar. SIP tidak dimaksudkan untuk menggantikan metodologi arsitektur enterprise yang ada. Hal ini dimaksudkan untuk menawarkan meta-metodologi dalam metode mereka. Meta-metodologi ini membahas problem metodologi yang mengabaikan kompleksitas.
4. KESIMPULAN
Kegagalan dalam mengorganisir kompleksitas IT yaitu alasan terbesar yang membuat metode IT sering gagal. Dan saat kompleksitas mulai terasa, kegagalan menjadi peristiwa, mahal, dan biasanya sungguh mencolok. Contoh kegagalan yang disebabkan sebab kompleksitas meresap di sektor publik dan swasta, merugikan biaya dengan rentang nilai mulai dari puluhan ribu sampai miliaran dolar.
Pendekatan Partisi Iteratif betul-betul terkonsentrasi pada pengendalian kompleksitas arsitektur enterprise. partisi digunakan untuk secara dramatis meminimalkan kompleksitas keseluruhan, sering dengan berulang kali lipat. Arsitektur enterprise divalidasi melalui proses terkendali prioritas dan iterasi.
Framework yang sudah mengimplementasikan pendekatan Partisi Iteratif yaitu: Simple Iterative Partitions (SIP) yang digunakan oleh NASA untuk memprediksi konsumsi bahan bakar.
_______________________________________________________
Author: Philip Faster, Ayasophia Arishinta, Pramuditha Shinta D. P.
Magister Sistem Informasi, Institut Teknologi Sepuluh Nopember
Referensi:
- Barrett, L., & Gallagher, S. (2003). McDonald’s: McBusted. Retrieved Januari 2, 2013, from http://www.cob.sjsu.edu/gaines_j/Bus188%20Materials/McDonald%20case.htm
- Carr, D., & Cone, E. (2001). Code Blue. New York: Baseline.
- Keefe, P. (2004). Oops! Ford and Oracle mega-software project crumbles. Retrieved Januari 3, 2013, from ADTmag:
- Sessions, R. (2006). A Better Path to Enterprise Architectures. Retrieved Januari 2, 2012, from MSDN: http://msdn.microsoft.com/en-us/library/aa479371.aspx
- Sessions, R. (2007). Controlling Complexity in Enterprise Architectures. Retrieved Januari 4, 2013, from ObjectWatch, Inc.: http://www.objectwatch.com/whitepapers/ControllingComplexity-1.pdf
- Strandler, J. (2007). Partitioned-Iterative more appropriate for EA than Zachman, TOGAF? Retrieved Januari 6, 2013, from InfoQ: http://www.infoq.com/news/2007/07/partitioned-iterative
- Wikipedia. (2012). Enterprise architecture. Retrieved Januari 3, 2013, from http://en.wikipedia.org/wiki/Enterprise_architecture