SOA Resurrected

May 2nd, 2010

SOA is Dead

Anne Thomas Mannes, seorang Research Director dari Burton Group, membuat sebuah artikel yang berjudul “SOA is Dead, Long live  Services”. Mantan CTO (Chief Technical Officer) dari Systinet, salah satu perusahaan terdepan yang menyediakan tools SOA Governence, ini mengatakan bahwa sekarang SOA sudah menjadi “Bad Word” dikalangan pebisnis Amerika Serikat dan mereka sudah tidak percaya lagi bahwa SOA akan memberikan efek spektakuler seperti yang dielu-elukan selama ini.

Mengapa hal ini bisa terjadi? Pada tulisannya Anne menggambarkan sebuah illustrasi berupa seekor dinosaurus yakni SOA yang akan tertimpa sebuah meteor.

Bila kita kembali ke masa lalu, dinosaurus disebutkan punah dikarenakan sebuah event besar, yakni jatuhnya meteor ke bumi. Hal itu pula yang ingin digambarkan Anne, bahwa kini SOA sudah punah dikarenakan sebuah event yakni krisis ekonomi di Amerika Serikat. Ia menyatakan bahwa kini kebanyakan perusahaan telah memotong dana untuk proyek SOA mereka. Hal ini dikarenakan mereka sudah lelah akan proyek SOA mereka yang nyatanya tidak memberikan efek yang lebih baik jika dibandingkan dengan kondisi sebelum implementasi SOA. Belum lagi dana yang cukup besar yang harus dikeluarkan untuk proyek tersebut.

Ia juga menyatakan bahwa kebanyakan orang masih terjebak dalam debat “apakah ESB yang terbaik”, atau “Manakah yang lebih baik WS-* atau REST” dan lupa akan esensi sebenernya dari SOA yakni Services dan Architecture. Dan hal tersebut lah yang menyebabkan banyak perusahaan gagal mengimplementasikan SOA.

Lebih lanjut lagi menurutnya, walaupun term SOA akan lebih jarang digunakan dikemudian hari namun permintaan akan sebuah arsitektur yang menekankan pada service itu sendiri akan bertambah besar. Hal ini dikarenakan munculnya konsep-konsep lain yang berlandaskan Services seperti mash-up, SaaS, dan Cloud Computing, yang membawa revolusi di dunia IT.

SOA Resurrected, in Indonesia offcourse

Pendapat Anne sangat benar sekali, bahwa SOA sudah mati. Tapi hal tersebut terjadi di Amerika, setelah ekonominya runtuh dengan krisis yang terjadi. Buruknya iklim ekonomi membuat seluruh perusahaan di sana mengencangkan ikat pinggang, dan anda bisa menebak apa yang pertama kali dipangkas budgetnya? Benar sekali, investasi-investasi yang dinilai tidak memberikan return besar bagi perusahaan. Dan kurang beruntungnya lagi, investasi IT adalah investasi yang banyak memberikan keuntungan secara intangible (tidak dapat dilihat kasat mata, misalnya kemudahan dalam bekerja), apalagi SOA yang implementasinya memakan banyak waktu dan uang.

Di Indonesia sendiri, dampak dari krisis tersebut masih belum terasa sangat besar dan kata-kata SOA masih jarang terdengar di dalam perusahaan. Sentimen perusahaan akan teknologi yang bernama SOA pun masih belum terdengar, bahkan beberapa perusahaan Client tempat saya bekerja menanyakan info tentang SOA dan ada keinginan untuk mencoba-coba mengimplementasinya.

Belum lagi, hype akan Cloud Computing (Service Cloud) dan juga metode computing lain yang “berbau” service (Software as a Service, Platform as a Service, etc) tentunya akan membawa nama SOA, yang merupakan arsitektur utama untuk menjalankan metode computing tersebut tersebut.

Namun ada beberapa hal yang harus diperhatikan mengenai positifnya pendapat perusahaan akan teknologi SOA tersebut. Yang menjadi penentu suksesnya implementasi SOA adalah bukan soal ESB apa yang kita pakai ataupun package SOA dari perusahaan mana yang kita pakai, melainkan bagaimana menyatukan konsep Bisnis perusahaan dengan IT ke dalam service-service. SOA is not about technological issues, but it’s about aligning IT with your business so they can walk side-by-side. And if all Indonesian company cannot deeply understand this issue, it’s not impossible that the same thing happened on USA, will be happening here.

Story

Setelah pada episode sebelumnya kita membahas mengenai Knowledge Management secara teori, pada kesempatan kali ini saya mencoba menceritakan mengenai pengalaman pribadi saya dalam salah satu bagian Knowledge Management, yakni Knowledge Transfer.

Suatu ketika saya ditugaskan oleh kantor saya untuk menggantikan seorang Senior Consultant di sebuah perusahaan financial terkemuka di Jakarta, sebut saja inisial perusahaan tersebut ACC (Astra Credit Company). Merasa senang sekaligus tertantang dengan tugas yang baru, saya pun bersemangat pada hari pertama saya ditugaskan ke Client tersebut. Namun sesampainya di sana, saya tidak langsung dihadapkan dengan kerjaan-kerjaan, yang saya kira, bakal menguras tenaga saya di hari itu. Hal itu dikarenakan semenjak hari itu dan 29 hari berikutnya kegiatan saya hanya berupa Knowledge Transfer, kata Senior saya.

Mendengar sebutannya yang keren (Knowledge Transfer), rasa penasaran dan ekspektasi saya akan aktivitas tersebut semakin besar. Kemudian setelah satu hari berlalu saya pun mengambil kesimpulan, bahwa Knowledge Transfer adalah “kegiatan yang membosankan”. Bayangkan saja, satu hari tersebut saya lewati dengam membaca dokumen-dokumen teknis dari seluruh program yang ada di ACC.

Hari kedua pun datang, dan rasa malas saya akan kegiatan kemarin membuat ekspektasi saya pada hari kedua berbalik 180 derajat. Namun ternyata nasib berkata lain, karena kegiatan saya sedikit tidak membosankan dibanding hari sebelumnya. Hari tersebut saya lalui dengan membuat simulasi program, setelah sebelumnya Senior saya menerangkan sedikit tentang konsep pemrograman pada PL/SQL Web, bahasa pemrograman yang digunakan di ACC untuk men-develop seluruh module Custom Oracle HRMS. Dan di akhir hari, senior saya pun mengadakan review akan apa yang sudah saya buat di hari itu dan apa yang akan saya pelajari berikutnya.

Hari-hari berikutnya pun saya lewati dengan kegiatan yang sama, yakni diskusi tentang konsep dan alur program yang ada, konsep pemrograman dan juga mencoba men-develop beberapa modul PL/SQL Web untuk menerapkan apa yang sudah didiskusikan sebelumnya. Dan diakhir bulan tersebut saya pun dapat menjawab pertanyaan bahwa sebenarnya proses Knowledge Transfer adalah update pengetahuan dari seseorang ke orang lain sehingga mereka dapat memiliki knowledge yang sama.

Bayangkan betapa kesulitannya saya, jika saya langsung dihadapkan dengan pekerjaan tanpa adanya proses pentransferan Knowledge tersebut. Bahkan saya sendiri merasa, bahwa satu bulan yang diberikan untuk proses Knowledge Transfer pun belum cukup karena kenyataannya masih banyak module-module yang belum diajarkan kepada saya.

Lesson Learned

Kemudian setelah beberapa bulan dilalui di sana, saya pun menyadari beberapa hal terkait knowledge management tersebut. Hal pertama bahwa senior saya sangat baik mewariskan banyak file yang dapat saya pelajari. Hal kedua bahwa seluruh file tersebut ternyata kurang berguna, karena tidak ada pengelompokan file yang benar berdasarkan module yang ada dan mana file yang masih dipakai dan mana yang tidak. Sebagai contoh, ketika saya ingin mengetahui seperti apa sih alur Sistem Perjalan Dinas Online, maka hal pertama yang saya lakukan adalah mencari technical maupun functional design-nya baru saya akan masuk ke coding. Namun saat masuk ke folder “File Anz” tersebut, saya hampir bisa menemukan 5 file dengan konteks yang sama atau kebingungan mencari di folder mana file tersebut berada, karena penamaan foldernya masih seperti “1 Juni 2010” untuk hampir lebih dari 30 folder yang berada di direktori tersebut (file Anz), belum lagi banyak yang masih memiliki sub-folder dengan penamaan yang sama (docs, 1-januari-2010, etc).

Pekerjaan utama saya di ACC adalah sebagai konsultan untuk me-support module Oracle HRMS, khususnya yang di-custom oleh ACC, dengan kata lain error dan debug adalah hal yang akan saya hadapi setiap harinya. Dan setelah 3 bulan berlalu, saya baru menyadari bahwa ada beberapa error dengan kode yang sama (misalnya error Unique Constraint : ORA 00001) dan cara pemecahan yang sama tentunya. Saya kemudian membayangkan, bagaimana jika ada sebuah file yang memuat seluruh list error yang pernah dialami seluruh konsultan Intelfast (perusahaan saya) lengkap dengan catatan how to solve-nya. Tentunya hal tersebut akan sangat membantu, khususnya ketika proses Knowledge Transfer.

Dari beberapa hal tersebut kemudian saya dapat mengambil kesimpulan, bahwa selain proses pentransferan Knowledge itu sendiri (diskusi dan juga simulasi) ternyata kita perlu mempersiapkan hal lain, yakni seluruh dokumentasi (file-file) yang juga berisi Knowledge yang akan di-transfer. Keseluruhan file tersebut tentunya harus dapat disusun secara teratur sehingga orang yang akan kita transfer ilmunya dapat mencari dan memahami Knowledge dengan mudah. Sebuah hal simple, yang ternyata jika dilakukan sangat besar manfaatnya terutama bagi penerus kita

Sebelum kita masuk lebih jauh ke dalam Knowledge Management, pertama-tama kita mesti tau apa si “mahluk” yang bernama knowledge ini?

Knowledge, baik itu dalam “bahasa” Filsuf ataupun IT, memiliki makna yang sama yakni kemampuan seseorang menyelesaikan sebuah masalah atau problem. Sebagai contoh ketika kita naik ojek dan tiba-tiba dihadang macet, sang tukang ojek pun mengambil jalan pintas melewati gang-gang, dan dengan luwes ia bisa melewati gang yang sempit dengan cepat dan sampai ditujuan tepat waktu. Sang tukang ojek tersebut dapat kita katakan memiliki knowledge lebih dalam mengendarai motor, khususnya pada daerah yang ia biasa lewati.

Lalu apa si yang menjadi permasalahan dari Knowledge ini, sehingga harus ada satu bidang khusus yang membahas gimana cara me-manage-nya?

Salah satu alasannya adalah karena Knowledge tersebut terbagi menjadi banyak jenis, sebagai contoh saya akan mengambil dua diantaranya yakni Tacit Knowledge dan Explicit Knowledge.

Kembali lagi ke sang tukang ojek, kemampuannya untuk dapat mengendarai motornya dengan luwes dan cepat melewati gang-gang kecil biasa disebut sebagai Tacit Knowledge, yakni Knowledge yang sangat melekat pada diri masing-masing individu. Tacit Knowledge ini sangat susah untuk ditransfer ke orang lain, dan biasanya didapat setelah orang tersebut Expert dengan knowledge-nya ini. Sebagai contoh ketika sang tukang Ojek ingin mewariskan keahliannya ini ke penerusnya, maka belum tentu penerusnya tersebut bisa mengendarai motor seluwes dan secepat tukang ojek itu. Sang tukang ojek pun biasanya akan kesusahan dalam men-transfer knowledge tersebut, karena hal itu melekat di dirinya setelah berpuluh-puluh tahun melanglang buana di dunia per-ojekan.

Namun hal tersebut sangat bertolak belakang dengan Explicit Knowledge, yang bisa diartikulasikan dan disampaikan dengan mudah ke orang lain. Pengetahuan tukang ojek akan rute-rute gang yang kosong ketika macet bisa digolongkan ke dalam Explicit Knowledge, karena ketika ia ingin mewarisi pengetahuannya tersebut ke penerusnya, ia dapat dengan mudah menjelaskannya secara verbal ataupun menggambarkan rute tersebut pada sebuah kertas agar sang penerus dapat memahami Knowledge tersebut.       Berbeda jenis Knowledge-nya, berbeda pula metode yang dilakukan untuk mentransfer knowledge-nya, dan berbeda pula cara me-manage-nya. Hal di atas baru dua diantara sekian banyak jenis knowledge yang tentunya tidak dapat di-manage secara general di perusahaan.

Kemudian apa yang membuat perusahaan mau melakukan Knowledge Management di tempatnya?

Pernahkah anda mengalami sebuah masalah dalam perusahaan, dan ketika anda menyadari ternyata sudah ada staff lain yang pernah mengalaminya dan melakukan problem solving yang sama? Pernahkah anda menyadari jika tumpukan notulen rapat anda yang ada di laci arsip anda ternyata menyimpan banyak informasi dan pemecahan masalah yang bisa saja menimpa anda? Pernahkah anda mencari seorang expert untuk menyelesaikan masalah anda, padahal ternyata teman satu kantor anda juga expert di bidang tersebut?

Permasalahan di atas lah yang akan dijawab dengan adanya Knowledge Management di perusahaan. Bayangkan berapa waktu dan effort yang anda hemat, jika anda dapat melakukan searching pada sebuah repository dari pemecahan masalah yang pernah terjadi dan di-solve di organisasi anda?

Tidak hanya itu pula, Knowledge Management juga bermanfaat dalam menjaga Knowledge tetap ada di perusahaan, misalnya ketika seorang staff expert meninggalkan perusahaan anda, anda tidak perlu kebingungan akan nasib Knowledge yang ada pada dirinya karena Knowledge tersebut tersimpan dalam suatu repository dimana seluruh staff, termasuk pengganti sang expert, bisa mengaksesnya dan meng-update knowledge mereka masing-masing.

Kalau begitu apa si hubungannya Knowledge Management dengan IT?

Peranan IT penting dalam Knowledge Management, karena ia adalah tools bagi perusahaan untuk melakukan Knowledge Management. Salah contoh yang paling mudah ditemui adalah penggunaan Corporate Wiki, dimana para staff perusahaan dapat berkontribusi dan berkolaborasi mengupdate aplikasi tersebut dengan knowledge yang mereka miliki, sehingga ketika Staff lain mengalami problem yang sama maka ia dapat mengakses wiki tersebut untuk menemukan pemecahan masalahnya.

Nah sekian saja pengenalan untuk Knowledge Management kali ini, Next Issue: Knowledge Management and Data Warehouse- Is It Related?