Sebuah Gambaran Singkat dan Pendekatan dalam Penyederhanaan Kompleksitas Arsitek Enterprise: Sebuah Review

Sebuah Gambaran Singkat dan Pendekatan dalam Penyederhanaan Kompleksitas Arsitek Enterprise: Sebuah Review


ABSTRAK
Kegagalan dalam mengelola kompleksitas IT adalah alasan terbesar yang membuat sistem IT sering gagal. Dan ketika kompleksitas mulai terasa, kegagalan menjadi bencana, mahal, dan biasanya 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.Pendekatan Partisi Iteratif benar-benar terfokus pada pengendalian kompleksitas arsitektur enterprise. partisi digunakan untuk secara dramatis mengurangi kompleksitas keseluruhan, sering dengan beberapa kali lipat. Arsitektur enterprise divalidasi melalui proses terkendali prioritas dan iterasi. Pendekatan partisi iteratif yaitu meningkatkan tingkat kesuksesan keseluruhan proyek. Dan dapat memampatkan waktu jauh lebih banyak. Hal ini karena desain tiap partisi hanya membutuhkan staf yang secara langsung terlibat dalam partisi. Framework yang ada saat ini sudah mulai mengimplementasikan pendekatan partisi iterative. Contoh framework yang menggunakan pendekatan ini yaitu SIP (Simple Iterative Partitions).

1. Pengenalan

1.1 Latar Belakang
(Sessions, 2007) Hampir segala sesuatu dalam organisasi besar dapat menjadi lebih kompleks. Di sisi bisnis, persyaratan dan peraturan, hubungan kemitraan, merger, dan akuisisi semua membuat proses bisnis menjadi lebih kompleks. Di sisi teknologi, model distribusi baru, tuntutan interoperabilitas tinggi, dan otomatisasi alur kerja menjadikan sistem IT lebih kompleks.

Hal ini menjadi sebuah tantangan untuk membangun sistem IT yang sangat kompleks, memastikan bahwa sistem tersebut memenuhi kebutuhan proses bisnis yang semakin kompleks, dan melakukannya dengan cara yang memungkinkan segala sesuatu beradaptasi dengan cepat terhadap perubahan kondisi pasar.

Kegagalan dalam mengelola kompleksitas IT adalah alasan terbesar yang membuat sistem IT sering gagal. Dan ketika kompleksitas mulai terasa, kegagalan menjadi bencana, mahal, dan biasanya 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 memahami kegagalan berbagai 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 sistem sistem tersebut, yaitu kompleksitas. Semua sistem ini sangat kompleks. Kelemahan utama FEAF, TOGAF, dan Zachman adalah kegagalan mereka untuk mengelola kompleksitas sistem. (Sessions, 2006)

Menyusun kompleksitas yang ada dan menyajikannya dalam bentuk yang mudah dipahami, telah lama digunakan oleh para perancang bangunan dalam menyajikan rancangan bangunan yang mereka usulkan. Disiplin arsitektural ini kemudian tumbuh menjadi satu disiplin yang menandai perkembangan peradaban manusia saat ini.

(Sadat, 2007) Perkembangan yang cepat dalam teknologi informasi, juga telah meningkatkan tingkat kompleksitas penggunaan teknologi informasi. Meningkatnya kompleksitas ini menuntut upaya lebih bagi para pengembang teknologi untuk menyajikan penjelasan sederhana atas penggunaan teknologi bagi kalangan lainnya. Penjelasan sederhana tersebut sering dipahami sebagai arsitektur teknologi informasi. Sayangnya, ragam gaya penyajian arsitektur kemudian mengaburkan pemahaman arsitektur teknologi.


1.2 Tujuan
Paper ini menjelaskan bagaimana kompleksitas arsitektur enterprise IT sejalan dengan bertambah besarnya enterprise itu sendiri. Beberapa solusi dirangkum untuk mempermudah pemahaman tentang menyederhanakan atau mengontrol kompleksitas itu. Kontribusi paper ini yaitu untuk mendeskripsikan gambaran tentang Arsitektur Enterprise dan penggunaan partisi iterative dalam penyederhanaan kompleksitas Arsitektur Enterprise.


2. Kompleksitas Arsitektur Enterprise

2.1 Definisi Arsitektur Enterprise
(Sessions, 2006) Arsitektur enterprise adalah 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 memberikan strategi yang memungkinkan organisasi mendukung adanya keadaan yang sekarang dan juga bertindak sebaga roadmap menuju lingkungan yang ditargetkan.

Sebuah Arsitektur enterprise berfungsi mengkolaborasikan perencanaan strategis perusahaan dan perencanaan kinerja dengan enterprise data architecture, enterprise application architecture, dan enterprise technical architecture (Hendley, 2008). Arsitektur enterprise merupakan suatu fungsi bisnis yang berkelanjutan yang membantu ‘enterprise’ mencari cara untuk mengeksekusi mana strategi yang terbaik yang mendorong perkembangannya.

Dalam mengembangkan arsitektur enterprise, terdapat beberapa alat bantu yang dikenal sebagai architecture framework. Architecture framework memiliki model simbolis untuk menspesifikasikan berbagai fase arsitektur enterprise. Dari sebuah model simbolis diinterpresentasikan makna dari dari masing-masing simbol pada sebuah model. relasi antara model semantik dengan arsitektur dapat dipahami dengan memahami tujuan dari modeling terlebih dahulu untuk memprediksi realitas dari keadaan yang sebenarnya. Didalam sebuah arsitektur enterprise harus terdapat sebuah panduan standar, kebijakan dan aturan-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 telah di kritik berat untuk menyia-nyiakan lebih dari 500 juta USD karena gagal dalam menciptakan sebuah virtual case-filing system. FEMA menghabiskan lebih dari 100 juta USD untuk sebuah sistem yang terbukti tidak efektif menangani Badai Katrina. Kelompok Federal lainnya yang telah menjadi subyek kritik GAO termasuk Biro Sensus, Badan Penerbangan Federal, Penerbangan dan Antariksa Nasional, HUD, Kesehatan dan Layanan Manusia, Medicare, dan MedicAid.

Pemerintah AS berjalan tidak terlalu 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 lembaga. Tampaknya bahwa semakin penting lembaga pemerintah, semakin besar kemungkinan memiliki kegagalan dalam IT.

(Sessions, 2006) FBI telah di kritik berat untuk menyia-nyiakan lebih dari 500 juta USD karena gagal dalam menciptakan sebuah virtual case-filing system. FEMA menghabiskan lebih dari 100 juta USD untuk sebuah sistem yang terbukti tidak efektif menangani Badai Katrina. Kelompok Federal lainnya yang telah menjadi subyek kritik GAO termasuk 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 berita utama, sektor swasta juga terkadang ceroboh dalam hal TI skala besar. Kegagalan ini tampaknya sebagian besar disebabkan karena kegagalan dalam metodologi arsitektur enterprise, contohnya:
  1. Upaya McDonald gagal dalam membangun sebuah sistem manajemen bisnis yang terintegrasi yang akan menyatukan seluruh bisnis restoran mereka. Biaya: $ 170 juta.  (Barrett & Gallagher, 2003)
  2. Upaya Ford gagal dalam membangun sistem pembelian yang terintegrasi. Biaya: $ 400 juta. (Keefe, 2004)
  3. 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 sebuah kompleksitas? Sebagai analogi, bayangkan peluncuran ke bulan. Sebuah peluncuran ke bulan adalah usaha yang sangat kompleks. Misalkan kita tidak memiliki model untuk gravitasi dan gerakan planet. Tanpa model seperti itu, setiap keputusan tentang peluncuran ke bulan, dari jumlah bahan bakar, kekuatan dorong, sampai 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 adalah sebuah dadu. Model ini memiliki keuntungan intuitif, visual, prediksi, dan matematis. Semisal perbandingan kompleksitas dua sistem yaitu, Sistem A dan Sistem B, seperti yang ditunjukkan pada Gambar-1. Suatu sistem terdiri dari dua sisi (yaitu, koin), sedangkan Sistem B terdiri dari enam sisi dadu (yaitu, dadu standar).
                                                                                                                                 

Gambar 1. Sistem A dan Sistem B

Sistem A hanya memiliki dua sisi potensial: kepala dan angka. Sistem B memiliki enam sisi potensial: 1, 2, 3, 4, 5, dan 6. Berdasarkan perhitungan matematis, Sistem B adalah 6/2, atau 3 kali lebih kompleks daripada A. Secara umum, jumlah state dari sistem dimana D adalah dadu, dan S adalah sisi, adalah SD. Dengan rumus ini, kita dapat menghitung kompleksitas sistem yang lain.

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, seperti yang ditunjukkan pada Gambar 2.


Gambar 2. Sistem B dan Sistem C

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 mendapatkan sebuah kebenaran. Jika Anda memprediksi hasil tertentu dengan melemparkan dadu dalam Sistem B, maka Anda akan memiliki kesempatan 1 : 6 untuk mendapatkan hasilnya. Jika Anda akan membuat tebakan berulang untuk kedua sistem, Anda akan benar 36 kali lebih sering dengan Sistem B daripada dengan Sistem C. Karena Sistem B lebih sederhana daripada 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 memberikan seperangkat aturan agar dapat membantu Anda lebih sukses dengan pendekatan ini.

Untuk menyederhanakan kompleksitas arsitektur enterprise dapat menggunakan pendekatan partisi iteratif. partisi digunakan untuk secara dramatis mengurangi kompleksitas keseluruhan, sering dengan beberapa kali lipat. Arsitektur enterprise divalidasi melalui proses terkendali prioritas dan iterasi.


3.2.      Partisi
Dengan model kompleksitas dasar, kita bisa mendapatkan gambaran bagaimana sistem yang kompleks dapat lebih terorganisir. Sebagai contoh, kita bandingkan dua sistem, Sistem C dan D Sistem, keduanya terdiri dari tiga dadu bersisi enam. Dalam Sistem C, semua dadu bersama-sama, seperti sebelumnya. Dalam Sistem D, dadu dibagi menjadi tiga partisi. Dua sistem ini ditunjukkan pada Gambar 3.


Gambar 3. Sistem C dan D Sistem

Diasumsikan bahwa kita bisa berurusan dengan tiga partisi mandiri, tiga subsistem, masing-masing seperti 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, yaitu 61, atau 6. Kompleksitas Sistem D seluruhnya 6 +6 +6, atau 18.

Secara umum, kompleksitas sistem dimana P adalah partisi, dan masing-masing dengan kompleksitas C, adalah 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 dilakukan Sistem D). Maka, kompleksitas dari sistem non-partisi (misalnya, Sistem C) selalu SD, dan kompleksitas dari sistem partisi (misalnya, Sistem D) selalu S x D.

Bagaimana dua rumus (S x D) dan (SD) dibandingkan satu sama lain. Tabel 1 menunjukkan nilai yang berbeda untuk S, D, rumus partisi (S x D), dan formula non-partisi (SD).


Tabel 1. kompleksitas Partisi vs kompleksitas non-partisi

Dengan Tabel 1, kita dapat melihat berapa banyak kompleksitas sistem non-partisi dari 9 dadu, dibandingkan dengan sistem partisi dengan jumlah dadu yang sama. Perbandingan tersebut hingga 10.077.696 berbanding 52.

Pada Tabel 1 dimana semakin besar kompleksitas dari keseluruhan sistem, maka dampak partisi semakin besar dan memiliki dampak terhadap berkurangnya kompleksitas itu. Petunjuk nomor satu tentang bagaimana menangani kompleksitas yaitu: partisi.


3.3       Iteratif
Setelah kita menggunakan partisi untuk mengurangi 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, seperti yang ditunjukkan pada Gambar-4.

Gambar 4. partisi dadu

Dalam pendekatan kompleksitas iteratif, kita menganalisis partisi masing-masing individu. Misalnya, pertama-tama kita menganalisis Partisi 1. Kemudian, menganalisis Partisi 2 dan terus sampai setiap partisi dianalisis. Pendekatan kompleksitas rekursif  menganalisis lapisan horizontal setiap partisi. Misalnya, pertama-tama menganalisis kasus di mana semua dadu berada. Analisis ini dilanjutkan sampai dengan menyelesaikan kasus terakhir yang memungkinkan untuk semua partisi. Namun, Dalam menganalisis kompleksitas, iterasi cepat hampir selalu menghasilkan hasil yang lebih baik daripada analisis mendalam. (Sessions, 2006)


3.4       Partisi Iteratif
Sekarang kita memiliki dua pelajaran tentang bagaimana mengelola kompleksitas arsitektur enterprise. Dari studi dadu, kita dapat mengetahui bahwa kompleksitas partisi adalah salah satu kunci untuk mengurangi kompleksitas. Dan dalam menganalisis kompleksitas, iterasi cepat hampir selalu menghasilkan hasil yang lebih baik daripada analisis mendalam

Kita bisa berasumsi bahwa contoh sebelumnya kegagalan arsitektur (misalnya, kegagalan dalam Kasus FBI Virtual File System atau manajemen bisnis McDonald) semuanya didasarkan pada metodologi arsitektur enterprise standar seperti FEAP, TOGAF, dan Zachman. Metodologi ini semua non-iteratif. Hal ini tidak mengherankan, karena itu, bahwa mereka semua gagal. Ini juga tidak mengherankan bahwa kegagalan mereka yang sangat mahal. Tahap-tahap berikut harus ada dalam Metodologi arsitektur enterprise :
  • Desain arsitektur bisnis
  • Desain arsitektur teknis
  • Implementasi
  • Pengujian
  • Penyebaran/pemasaran

Metodologi tradisional mengambilnya sebagai satu fase pada suatu waktu, kemudian menyelesaikan satu secara keseluruhan sebelum yang berikutnya dimulai. Hal ini ditunjukkan pada Gambar-5.




Gambar-5. Pendekatan mega desain

Seperti ditunjukkan dalam Gambar-5, metodologi tradisional dimulai dengan arsitektur bisnis yang mendalam dari sistem target. Pendekatan partisi iteratif terlihat cukup berbeda. Gambar-6 menunjukkan pendekatan partisi iteratif dalam tindakannya. Perhatikan bahwa tahapannya sama seperti sebelumnya, tapi sekarang dilakukan partisi demi partisi.

Gambar 6. Partisi iterasi

Hasil dari pendekatan partisi iteratif adalah aliran konstan yang keluar dari fungsionalitas. Sebuah partisi tidak akan dijalankan sebelum partisi sebelumnya selesai. Dalam organisasi yang kompleks dan besar, jarang terdapat proyek simultan secara paralel, tetapi jumlahnya harus dijaga seminim mungkin, terutama di iterasi awal. Beberapa proyek yang bersamaan akan meningkatkan kebutuhan untuk koordinasi.


3.5       Implementasi Pendekatan Partisi Iteratif
(Sessions, 2006) Keuntungan dari implementasi pendekatan partisi iteratif yaitu meningkatkan tingkat kesuksesan keseluruhan proyek. Hal ini dikarenakan penerapan iterasi sebelumnya dapat menjadi pelajaran untuk iterasi selanjutnya.

Semisal teridentifikasi masalah dalam akurasi waktu yang dibutuhkan untuk melatih para developer. Ketika menangani antarmuka call center, sudah harus dapat dipastikan penetapan pengembang mana yang berpengalaman. Jika tool pengembangan lebih rumit daripada yang direncanakan, maka dapat dipertimbangkan tool lainnya. Jika proses memakan waktu lebih lama dari rencana, jadwal sudah dapat disesuaikan dengan waktu yang tersisa.

Titik penting yaitu dengan iterasi dipartisi dapat ditemukan masalah awal, sebelum mereka menghancurkan seluruh proyek. Dan, jika mereka tidak bisa diperbaiki, setidaknya mereka dapat dikenali sebelum penundaan yang mengejutkan manajemen. Keuntungan lain dari iterasi dipartisi yaitu dapat memampatkan waktu jauh lebih banyak. Hal ini karena desain tiap partisi hanya membutuhkan staf yang secara langsung terlibat dalam partisi.

Sebuah  metodologi arsitektur enterprise yang didasarkan pada model 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 sama, ilmuwan NASA dapat menggunakan model gravitasi untuk memprediksi konsumsi bahan bakar. SIP tidak dimaksudkan untuk menggantikan metodologi arsitektur enterprise yang ada. Hal ini dimaksudkan untuk memberikan meta-metodologi dalam metode mereka. Meta-metodologi ini membahas masalah metodologi yang mengabaikan kompleksitas.


4. KESIMPULAN
Kegagalan dalam mengelola kompleksitas IT adalah alasan terbesar yang membuat sistem IT sering gagal. Dan ketika kompleksitas mulai terasa, kegagalan menjadi bencana, mahal, dan biasanya 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.

Pendekatan Partisi Iteratif benar-benar terfokus pada pengendalian kompleksitas arsitektur enterprise. partisi digunakan untuk secara dramatis mengurangi kompleksitas keseluruhan, sering dengan beberapa kali lipat. Arsitektur enterprise divalidasi melalui proses terkendali prioritas dan iterasi.

Framework yang telah 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:
  1. 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
  2. Carr, D., & Cone, E. (2001). Code Blue. New York: Baseline.
  3. Keefe, P. (2004). Oops! Ford and Oracle mega-software project crumbles. Retrieved Januari 3, 2013, from ADTmag: http://adtmag.com/articles/2004/11/01/oops-ford-and-oracle-megasoftware-project-crumbles.aspx
  4. Rouse, M. (2007). Definition: Enterprise Architecture (EA). Retrieved Januari 6, 2013, from Techtarget: http://searchcio.techtarget.com/definition/enterprise-architecture
  5. Sadat, A. (2007). Memahami IT Enterprise Architecture. Retrieved Januari 2, 2013, from Anwar 's JOURNAL: http://anwars78.blogspot.com/2007/11/memahami-it-enterprise-architecture_10.html
  6. Sessions, R. (2006). A Better Path to Enterprise Architectures. Retrieved Januari 2, 2012, from MSDN: http://msdn.microsoft.com/en-us/library/aa479371.aspx
  7. Sessions, R. (2007). Controlling Complexity in Enterprise Architectures. Retrieved Januari 4, 2013, from ObjectWatch, Inc.: http://www.objectwatch.com/whitepapers/ControllingComplexity-1.pdf
  8. 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
  9. Wikipedia. (2012). Enterprise architecture. Retrieved Januari 3, 2013, from http://en.wikipedia.org/wiki/Enterprise_architecture

Komentar