Denny Depok IT Blog

Sejak awal perkembangan komputer, kalangan bisnis adalah kalangan yang paling banyak mengeksploitasi teknologi informasi untuk membantu operasionalnya. Sesuai dengan perkembangan teknologi dari masa ke masa, muncul perangkat lunak-perangkat lunak yang yang dapat membantu operasi bisnis yang mampu buat pada masa tersebut. Dimulai dari aplikasi bisnis sederhana seperti text processor (dari WordStart, WordPerfect, MS. Word), spreadsheet (Lotus 123, Quattro, Excel), database (DBase, Paradox, Oracle), aplikasi spesial seperti ERP-CRM sampai sistem proses bisnis muktahir BPMS (Business Process Management System).

Jika melihat evolusi software perusahaan diatas, terlihat bahwa software perusahaan berkembang dengan semakin memasuki semua sendi-sendi bisnis untuk menuju suatu sistem informasi terintegrasi yang menjadi jantung dari pelaksanaan bisnis. Menurut pengamatan saya, dengan tersedianya infrastruktur IT yang sudah sangat memadai diperusahaan saat ini (mulai dari komputer disetiap meja staff yang terhubung ke jaringan, database besar yang mampu mengatur data jutaan/milyaran record, server-server yang mumpuni untuk proses komputasi perhitungan kompleks secara realtime), sudah saatnya sistem informasi perusahaan terintegrasi tersebut diimplementasikan saat ini. Perangkat lunak yang merupakan puncak atau holy grail dari software perusahaan yang saya sebut Integrated Enterprise Collaboration System (IECS).

Jadi bagaimanakah sistem informasi bisnis sempurna ini akan berbentuk ? Untuk menjawab pertanyaan tersebut kita perlu melihat struktur operasional organisasi bisnis saat ini yang bisa dilihat pada gambar dibawah ini (klik unutk gambar yang lebih besar).

Terlihat bahwa ada 4 lapisan penting dari organisasi. Lapisan pertama adalah struktur organisasi, yaitu bagaimana para staff dibagi berdasarkan bagian untuk mendapatkan tugas dan wewenang yang sesuai. Lapisan kedua adalah data, yaitu semua data yang berhubungan dengan operasi perusahaan, hal yang dialirkan diantara struktur organisasi selama operasional perusahaan sebagai darah organisasi. Lapisan ketiga adalah proses bisnis, yaitu lapisan yang menjelaskan bagaimana urut-urutan tugas diantara bagian untuk menyelesaikan pekerjaan tertentu. Lapisan keempat adalah aplikasi-aplikasi khusus yang dipergunakan untuk mengolah data tertentu.

Sistem informasi bisnis yang sempurna adalah sistem informasi bisnis yang mencapture semua lapisan-lapisan diatas. Mampu mengabstraksikan semua lapisan diatas secara lengkap dan mampu mengintegrasikan semua lapisan diatas menjadi satu view komprehensif terhadap perusahaan.

Bagai mana bentuk tepatnya… hmm mungkin bagi para staf, tampilan yang akan dilihat mirip dengan aplikasi yang dipakai mereka saat ini. Bedanya, tampilan yang mereka lihat benar-benar layar yang ditujukan untuk mengerjakan suatu tugas tertentu sesuai dengan state suatu pekerjaan, sebab aplikasi-aplikasi IECS adalah aplikasi proses bisnis dengan banyak state dan banyak user. Jadi layar kerja yang mereka hadapi adalah layar yang benar-benar tepat, tidak ada layar umum yang bisa dilihat semua orang seperti aplikasi perusahaan saat ini.

Yang benar-benar berbeda adalah layar yang dilihat oleh developer dan administrator. Layar yang akan mereka lihat akan menampilkan semua lapisan perusahaan dalam satu aplikasi development/setting. Tidak seperti yang ada saat ini semua lapisan punya aplikasi masing-masing dan parahnya sering tiap lapisan dihandle oleh orang yang berbeda sehingga sulit membuat aplikasi perusahaan yang benar-benar tepat dan komprehensif.

Arsitektur IECS akan terlihat seperti dibawah ini (klik untuk gambar yang lebih besar).

Gimana, tertarik dengan IECS ? Kalo tertarik, mungkin perlu melihat yang saya dan tim saltanera kerjakan selama 1.5 tahun terakhir (klik untuk lebih besar)

Salah satu ciri khas vendor software indonesia adalah hampir semua merangkak dari perusahaan kecil berisi 2 sampai 4 orang kemudian berkembang menjadi perusahaan yang memiliki staff sampai puluhan sampai ratusan (belum pernah denger vendor software indonesia sampe ribuan pekerjanya). Jarang sekali ada vendor yang sudah di set-up dari awal untuk menjadi perusahaan menengah/besar, walaupun ada biasanya hanya menjadi agen software dari luar negeri dan hidup dari proyek deployment.

Kondisi diatas biasanya membuat struktur organisasi vendor IT berubah-ubah sesuai perjalanan waktu. Pada waktu awal (waktu 2-4 orang), semua staff pada level C, maksudnya CEO, CTO, C project manager, C analis, C programmer dan C tester (bacanya si project manager, si analis, si programmer dan si tester, soalnya yang ngerjain orangnya itu-itu aja )

Setelah perusahaan maju, biasanya staff akan ditambah, mulai dari programmer, marketing, administrasi, dokumenter dan yang lain-lain. Tetapi karena projeknya belum banyak, resource yang tersedia biasanya disharing diantara beberapa proyek. Maksudnya satu programmer bisa ngerjain 2 sampe 3 proyek sekaligus. Apalagi analis, marketer , tester dan administrasi, biasanya sudah default disharing ke banyak proyek. Struktur organisasi ini biasa disebut struktur matriks, dimana satu orang bisa punya beberapa bos, bos dari departemen dan bos dari proyek. Tapi karena masih relatif sedikit proyeknya, bos departemen biasanya yang jadi project manager, jadi gak terlalu masalah. Dan biasanya yang jadi project manager adalah developer paling senior.

Masalahnya muncul kalo proyeknya makin banyak dan proyek gak bisa lagi dihandle sama development manager, sehingga akhirnya di-hire-lah orang-orang yang khusus jadi project manager. Masalahnya adalah pada saat transisi kepemimpinan dari dari development manager yang lebih dekat ke programmer (teknis) menjadi project manager sesungguhnya yang lebih deket ke manajemen. Pekerja yang dulu bisa kong-kalikong dengan project manager (karena project manager ngerti permasalahan yang dihadapi developer) gak bisa lagi santai-santai, karena project manager sesungguhnya lebih mentingin pencapaian tujuan seperti schedule ontime, sesuai budget dan kualitas yang baik.

Masalah yang timbul biasanya ada kasak-kusuk antar developer tentang project manager yang kelewat tegas. Sebenernya enggak kelewat tegas sih, emang itu tugasnya, tapi developer yang emang biasa santai (sedikit malas lebih tepatnya) jadi harus ngikutin aturan baru (yang seharusnya dilakukan dari dulu). Kalau sudah gitu biasanya ada sedikit pembangkangan masal dari developer ke project manager (yang sesungguhnya). Masalahnya lebih besar lagi kalau development manager (DM) (yang dulunya senior developer dan project manager awal) terprovokasi dengan kasak-kusuk tadi dan merasa kekuasaan dia tergerus oleh kedatangan project manager (PM). Perlu diingat, developer (terutama development manager) sudah bergabung ke perusahaan jauh lebih dahulu dari project manager yang baru ini, yang tentu aja kedekatan diantara mereka jauh lebih kuat daripada ke project manager baru. Apalagi PM biasanya kemampuan teknisnya agak kurang (tapi kemampuan manajemennya lebih tinggi) daripada DM, jadi sering diragukan keputusannya.

Pertarungan akan berlanjut apabila tekanan penyelesaian proyek meningkat. PM yang berusaha menekan developer untuk mempercepat penyelesaian project akan berhadapan dengan DM (yang sudah ngerasa kekuasaannya tergerus) yang berusaha memprotek anak buahnya dengan alasan beban anak buahnya sudah overload. Masalah lebih besar lagi kalau DM menolak menambah programmer (kalau struktur organisasi matriks, penambahan staff adalah wewenang DM). Akhirnya ketegangan gak bisa dihindarkan, saling curiga antara PM dengan DM dan saling cari kesalahan akan mewarnai kegiatan sehari-hari. Apalagi kalo developernya memanfaatkan ketegangan ini untuk memperlambat pekerjaan (percaya deh, kalo atasan berantem, bawahan jadi bisa leha-leha memanfaatkan kekanak-kanakan atasan tadi ).

Akhirnya ??? Pekerjaan jadi banyak yang terbengkalai. Perintah dari PM akan dimentahkan DM. Perintah dari DM akan dimentahkan PM. Akhirnya developer bingung mo ngerjain yang mana, ya akhirnya leha-leha aja. Kalo ditanya salah satu atasan, persalahkan atasan yang lainnya :D. Kalau sudah tahap ini, proyek banyak yang terlambat atau gagal. Klien kecewa dan membatalkan proyek-proyek yang selanjutnya. Dah akhirnya, tinggal tunggu pembubaran perusahaan.

Inilah hal yang sering terjadi di vendor software. Bukan tutup karena gak ada kerjaan, tapi tutup karena kebanyakan kerjaan.

Solusinya ??? Perlu diingat oleh semua orang kalau PM harusnya berkuasa penuh terhadap proyek. Kenapa ? karena PM bisa melihat lebih luas terhadap keseluruhan pekerjaan dibandingkan orang lain. Walaupun DM dengan developernya memiliki kemampuan teknis yang mumpuni, tapi gak cukup luas untuk melihat kalau proyek bukan sekadar mrogram, tapi ada perencanaan jadwal, perencanaan perubahan, penjaminan kualitas, hubungan dengan klien dan aspek legal yang cuma bisa dilihat dengan jelas oleh orang sekaliber PM.

Perusahaan yang merasa sudah besar sudah saatnya meninggalkan struktur matriks. Harusnya sudah berpindah ke struktur pohon seperti yang terlihat pada gambar diatas. Memang permasalahan DM jadi tidak ada. Perlu diingat DM biasanya developer yang paling senior yang biasanya sangat berjasa ke perusahaan bahkan mungkin ikut membangun perusahaan. Ya mau gak mau DM harus berubah fungsi, misal jadi manager untuk PM, jadi gak berhubungan langsung ke teknis. Atau kalau memang DM mau terus di level teknis, perusahaan bisa membuka departemen baru seperti departemen riset untuk membangun komponen software yang gak terbatas oleh jadwal waktu yang kaku.

Tapi tetep diinget, bagaimanapun struktur organisasinya, yang paling berpengaruh adalah tingkat profesionalisme setiap staff. Karena hal ini yang biasanya jadi hambatan kita sebagai bangsa indonesia yang biasanya mengutamakan hubungan baik antar personal sampai menghalalkan anomali-anomali yang ada.

Sebenernya ide ini dah lama, mungkin 2 ato 3 tahun lalu dah kepikiran. Sempet jadi kandidat tesis saya tapi abis itu dilupain gara-gara asik maen workflow :D. Trus daripada sia-sia, saya publish disini, siapa tau ada yang mo implement ato mo ngembangin lebih lanjut.

Ide awal gini, kan sekarang jumlah komputer yang terhubung ke internet dah banyak banget, buktinya IPV4 sampe habis. Nah kebanyakan, komputer yang terhubung ke internet itu keseringan idle, terutama komputer client yang cuma dipake untuk browsing, chatting ato nyari gambar dan video ****** (edited -red). Nah komputer-komputer client yang idle itu, walaupun disebt client, tapi rata-rata punya prosessor yang keren-keren, apalagi sekarang jamannya core duo ato lebih. Kan sayang banget daya komputasi yang tersedia berlimpah itu terbuang percuma.

Nah ide dari Paralax ini adalah gimana caranya orang-orang yang punya resource terbuang sia-sia tadi bisa nyumbangin resource komputasinya untuk kegiatan yang lebih berguna. Jadi diminta untuk ngejalanin program yang berguna, tapi gak terlalu menganggu kegiatan dia. Pasti dah pada mikir “Bukannya udah ada parallel computing dari dulu ?“. He..he..he.. emang sih udah ada, bahkan kayaknya udah mature banget. Tapi saya mo nekanin karakteristik dari pengguna-pengguna tadi yaitu :

1. Koneknya gak dedicated
Maksudnya kadang konek, kadang enggak. Ya tergantung maunya di user aja. Jadi sistem paralax ini harus bersikap pesimis, maksudnya gak berharap banget komputer client bakal konek terus. Trus juga harus clientnya yang minta duluan (ini programnya aja, bukan usernya ngelakuin manual), soalnya server kan gak tau kapan client mo online ato enggak.

2. Susah disuruh nginstall program

Maunya gak usah download-download langsung jalan aja. Jadi model paralel komputing lama yang mengharuskan user untuk download program host program paralel susah diimplementasiin sekarang.

3. Susah disuruh update program
Disuruh install aja susah, apalagi disuruh update program kalo misalnya ada perubahan perhitungan/algoritma. Makanya model paralel computing baru perlu diciptain.

Walau gaungnya gak sekenceng Ajax, usaha untuk menampilkan grafik 3D di web saat ini sebenernya mulai menunjukkan geliat yang cukup menarik untuk diamatin. Maksud saya bukan sekedar gambar 3D loh, tapi sistem grafik 3D yang interaktif, ya kayak digame-game 3D gitu deh. Sebenernya keinginan (ato obsesi malah) untuk menampilkan grafik 3D di web udah lama banget, mungkin ada yang masih inget sama VRML jaman dulu ?

Trus kalo emang udah lama kenapa baru mulai ribut-ribut sekarang ? jawabannya adalah dulu lingkungan yang tersedia untuk 3D di web feasible banget. Trus sekarang udah ? jawabannya belum :D :D.

OK gini deh saya mulai cerita dari VRML. Yang buat VRML sadar kalo projek mereka gagal, alasannya sih macem-macem, saya gak mau bahas disini ato malah debat kusir disini, tapi yang pasti makin lama suara VRML makin gak kedengeran. Melihat kenyataan tersebut, tim VRML mencoba untuk memperbaiki spek VRML agar dapat mengikuti struktur modern a.k.a XML, sehingga lahirlah X3D. Selain spek sintaks, X3d juga menambah kemampuan interaksi antara model 3D dengan lingkungan pemrograman yang diberi nama X3D SAI (scene application interface). Ya akhirnya model 3D dengan X3D ini bisa untuk membuat aplikasi 3D yang lumayan kompleks. Saya dah pernah buat aplikasi pake X3D, screenshotnya seperti gambar diatas itu. Gambar tersebut adalah gambar fraktal 3D dengan pendekatan LSystem.

Walaupun X3D punya banyak fitur, tapi gaungnya tetep gak kenceng, sampe nyoba membajak nama Ajax sehingga munculah Ajax3D seperti yang ada diweb www.ajax3d.org. Tapi tetep gak banyak yang tertarik, kalo dari analisa saya sih kebanyakan developer trauma dengan kegagalan VRML yang dulu sempet ngebooming banget tapi abis itu mati pelan-pelan. Menurut saya lagi ditambah kurangnya dukungan web browser (yang bagusnya sih otomatis include kemampuan X3d), trus apalagi belum ada plugin X3D yang bener-bener free ngebuat orang males make. Disuruh download plugin yang free untuk personal sebesar 5MB aja males, apalagi harus bayar kalo mo ngembangin aplikasi komersial untuk plugin yang performansinya gak begitu bagus.

Perkembangan lain dateng dari munculnya tag canvas di browser selain IE (firefox + opera tentunya, tapi google udah nyediain emulasinya untuk IE). Tag ini memungkinkan developer web unutk menggambar secara programming di dalam area canvas tersebut. Developer yang seneng maen grafik (termasuk saya :D :D) langsung excited banget untuk mengexploitasi fitur ini, dan tentu aja mulai berfikir untuk menampilkan grafik 3D dengan canvas tersebut. Dari percobaan saya untuk membangun 3D engine diatas canvas, hasilnya gak feasible banget :D :D, walau baru wireframe + shadding flat, untuk 100 surface aja dah lambat banget :D :D. Dari beberapa orang lain yang mencoba hasilnya gak jauh beda. Ya gimana lagi, canvasnya gak dioptimasi untuk pemrograman grafik yang rumit ditambah kecepatan javascript yang you know lah

Tapi sebenernya canvas memang sudah didesain untuk mengantisipasi grafik kompleks seperti 3D. Karena memang saat ini baru konteks 2D yang didukung, makanya ngebuat engine 3D manual pake javascript diatas konteks 2D seperti jamannya program DOS pengen nampilin 3D. Ada beberapa tim yang nyoba untuk ngebuat konteks 3D diatas canvas, minimal ada 2 yang udah saya denger, dari orang firefox dan orang opera. Tapi sayang kedua tim tadi memilih pendekatan yang berbeda.

Tim firefox mencoba mengembangkan dari OpelGL embedded, sedangkan opera mengembangkan dari model engine yang gak tergantung sama library 3D pipenya. Sebenernya sih keduanya ada keuntungannya, tapi sayang kalo gak sepakat. Tim opera berargumentasi kalo engine yangh gak tergantung library mudah unutk diimplementasikan diberbagai sistem sampe hardware seperti handphone. Kalo saya nempati diri sebagai orang manajemen, saya pasti ngedukung opera, ya kan enak sekali implementasi bisa buat hampir semua hardware. Tapi kalo sebagai programmer yang pernah maen-maen sama 3D, tim firefox tuh sangat benar sekali. Bukan apa-apa, kalo kita mrogram 3D, pasti ada aja yang harus kita buat sendiri, dan semakin low level (OpenGL kan langsung maen ke hardware) performansinya pasti lebih yahud. Lagian buat apa punya hardrware 3D bagus tapi gak bisa dipake optimal, ya tau sendiri lah, engine 3D kan dibangun berdasarkan ketersediaan hardware saat dibangun dan harus mengakomodasi banyak orang jadi mungkin gak optimal untuk kebutuhan tertentu.

OK deh, mungkin perlu waktu beberapa saat lagi sebelum canvas 3D didukung secara default di browser (firefox + opera ya, IE sih saya gak berharap banyak :D). Tapi percaya deh kalo tim-tim diatas akan menuntaskan tujuannya, untuk perkembangan yang firefox bisa dilihat di Canvas3D Forum Mozilla. Tapi sebenernya ada satu hal lagi yang belum dipegang sama tim-tim tersebut, yaitu matematika 3D. Pasti langsung banyak yang mikir kenapa harus khusus bikin untuk matematika 3D, kan tinggal bikin aja di javascript. Saya tau, saya tau. Tapi jangan lupa, kalo program 3D yang profesional tuh enggak ngitung matematika 3D secara programming standar, tapi make bantuan hardware. Ya kalo lupa saya bilangin deh, inget sama MMX/3D Now/SSE ? He..he..he.. emang gak banyak yang tau sih. Tapi intinya semua istilah tadi ngacu sama teknologi SIMD (Single Instruction Multiple Data). Maksudnya dengan sekali instruksi (jadi satu cycle CPU) bisa mengoperasikan perhitungan matematika terhadap beberapa data. Ya bayangin aja 3D kan maennya vektor yang berisi 3 data floating point, plus matriks 4×4 biasanya. Kalo pake programming biasa pasti prosesnya sebanyak datanya, tapi kalo pake SIMD cuma sekali jalan, asik kan ? Jadi mungkin objek Math-nya javascript harus dikembangin untuk operasi 3D dan matriks, tapi tentu aja mengeksploitasi MMX/3D Now/SSE. Nunggu ato harus saya sendiri yang buat ya :D

Walau banyak yang skeptis terhadap 3D di web seperti bilang buat apa, ya terserah mereka sih. Tapi saya yakin aplikasi 3D on web dimasa depan akan banyak banget. Kondisinya kayak gini deh, dulu orang nonton TV/Video ato denger radio/ nelpon lewan internet juga banyak yang bilang gak mungkin dan untuk apa, tapi setelah ada youtube + skype malah jadi makanan sehari-hari. Dan 3D di web, saya rasa bakan booming banget gak lama lagi, tinggal kita liat aja. Dari saya sendiri sih dah punya banyak benget ide 3D di web, tinggal ada yang mo sponsorin gak :D

Baru beberapa menit lalu saya ngobrol-ngobrol dengan teman saya tentang ribetnya system integration diperusahaan dia. Memang sih perusahaan tempat dia bekerja berurusan dengan data yang disharing beberapa pihak (ngambil dari beberapa tempat dan memberi ke beberapa tempat). Kebayang gak sih, disaat perusahaan-perusahaan lain di indonesia baru ribut-ributin masalah mo milih desktopbased/web based ato windows/linux, perusahaan dia dah ngurusin gimana gabungin beberapa sistem yang bener-bener beda (karena emang yang bangun beda-beda) trus ditambah usia masing-masing sistem berbeda-beda banget ada sistem baru yang dilengkapin fitur canggih kaya web service/corba/EJB, tapi gak sedikit sistem yang lahir waktu jaman-jamannya cobol/fortran :D

Saya excited banget untuk ngobrolinnya secara emang dah lama saya tertarik dengan system integration. Mungkin awalnya sewaktu saya bekerja di vendor salah satu bank swasta dan bertugas untuk membangun sistem yang bekerja dengan berbagai system core banking di bank itu yang kebanyakan masih jalan di IBM AS400 dan komputer-komputer server/mainframe lain yang saya gak pernah lihat wujudnya tapi sering saya akses lewat layar warna ijo :D.

System integration mungkin gak bisa dihindari oleh kita. Saat ini banyak perusahaan sudah punya puluhan hingga ratusan aplikasi yang perlu untuk saling bekerja sama agar makin efektif. Apalagi saat ini di dunia IT sepertinya ada semacam kesepakatan bahwa perbedaan platform mungkin sudah bukan hal yang perlu diperdebatkan lagi. Sekarang semua orang bebas untuk membangun aplikasi di platform/bahasa/framework manapun karena sulit untuk menentukan yang mana yang lebih unggul daripada yang lain. Tapi permasalahnnya muncul kalau aplikasi-aplikasi tadi harus diintegrasikan, baik diintegrasikan antar aplikasi internal perusahaan bahkan dengan aplikasi dengan pihak luar. Ada perusahaan yang mengambil keputusan dengan menstandarisasikan bagaimana aplikasi dibangun (mulai dari bahasa, framework, platform, database sampe style pemrograman), tapi jujur bagi saya sih langkah itu seperti minum racun untuk ngilangin sakit sekarang, tapi ngebuat mati di kemudian hari. Gimana ya, tehnik pembangunan perangkat lunak kan berkembang dengan cepat juga. Kalo distandarin, mungkin setengah/satu tahun kemudian muncul tehnik baru yang lebih efektif dan efisien dan ngebuat yang distandarin jadi gak menarik lagi. Bahkan ada perusahaan yang demi keidealannya menjaga standar akhirnya kesulitan untuk mencari programmer yang bisa menangani standar yang udah mulai ditinggalin itu.

Trus bagaimana dong untuk menghadapi integrasi antar aplikasi diperusahaan yang jumlahnya puluhan (bahkan ratusan sampe ribuan) ? Sayang gak ada cara mudah untuk menjawab tantangan tadi. Cara standarisasi (yang diatas sudah saya tentang) mungkin bisa menjawab sedikit masalah di integrasi sistem, ya paling enggak disisi cara komunikasi, tapi masih belum menjawab banyak tantangan lain.

Kalo dari saya, mungkin yang paling utama adalah kemauan dari sisi manajemen. Yup, sekali lagi kemauan manajeman. Kenapa saya bilang gitu ? Karena sesuai dengan pengalaman saya, kalo kemauan manajemennya kuat, kalo perlu sampe terobsesi, semua tantangan integrasi sistem tuh gak ada apa-apanya. Karena biasanya rintangan terbesar tuh adalah kemalasan para staf untuk melakukan integrasi itu. Ya biasa lah, staf kan maunya kerja dengan irama yang itu-itu aja, kalo udah bisa jalan (walau ada anomali dikit) gak pa pa lah, dari pada harus berubah dan nambah kerjaan (saat itu). Makanya orang manajemennya gak boleh berpikiran yang sama. Harus punya visi yang jelas tentang keuntungan yang bakal diraih dari mengintegrasikan sistem tadi dan bagaimana merencanakan pengintegrasian tersebut.

Yang kedua adalah kebijakan manajemen untuk mendorong semua aplikasi baru didesain untuk mengakomodasi akan diintegrasi di suatu saat nanti. Mungkin sekarang enggak, tapi harus mikir nanti bakalan diintegrasiin dengan yang lain. Kebijakan ini mirip dengan standarisasi, tapi cuma dilevel desain, jadi gak terlalu mengekang developernya tapi ngasih dorongan kedeveloper agar jangan berpikiran sempit. Hal ini bisa ngurangin kepusingan dikemudian hari.

Dan terakhir yang paling penting adalah milih staf yang akan melakukan integrasi adalah staf yang tingkat komprominya tinggi. Kenapa saya bilang gini ? Karena kita semua tau lah gimana sih gayanya programmer, sebagian besar nganggep dirinya sebagai artis besar yang egonya tinggi banget. Padalah disaat integrasi programmer tadi harus menghadapi desain/tehnik dari berbagai developer yang berbeda-beda yang mungkin berlawanan dengan keidealan keartisannya dia. Makanya staff yang kompromistis, yang milih cari solusi daripada nyari konfrontasi diperluin banget (i’ve been there  and see how bad things happen :D :D).

He..he..he.. sorry deh kalo disini cuma cuap-cuap dikit tentang system integration, kalo mo diskusi panjang tentang system integration sampe turun ke tehnik bisa email ke saya ke denny[at]klorofil.org.