red1 ipts system challenge

Amaran: Ini jawapan meleret panjang sangat. Jangan teruskan sekiranya tak rela. Maaf kerana di Kuang ini tiada awek menganggu maka konsentrasi saya amat tinggi.)

Terima kasih semua, memang otai belaka dan merata (melainkan Amin Ledang yang asyik fikir pasal seks. :) ). Soalan posting sepatutnya mengenai 'sizing' iaitu soalan asas dalam apa jua pembuatan sistem. Namun soalan sedemikian adalah soalan pra-pembangunan dan bukan tengah membangun sesuatu sistem ERP.
Sptmn ramai di atas menjawab, soalan itu ada beberapa pertimbangan dari perkiraan seperti saiz dan fungsi dan penting sekali design data, berpandu kepada corak penggunaan. Namun keyword yang saya selalu ada dalam kepala ialah 'sustainability' yakni soal tentang siapa dan bagaimana akan dipelihara 'anak' yang bakal dilahirkan nanti. Kerap sangat saya lihat, sistem itu lahir dengan riangnya seketika, tetapi keperluan sistem tidak statik sepertimana terbukti dalam soalan asal. Ia tetap membesar dan berubah. Sistem yang betul akan mengharungi secara agile, range dan maneuvarbility - tiga keywords memang ada dalam kitab terbitan Wiley mengenai IT architecture. Tetapi saya letak satu keyword besar - dokumentasi. Biasanya langsung tak ada, tuan puan.
Namun key question yang saya selalu tanya kat vendor besar termasuk sebuah ISP bernama Jaring tahun 2000 sehingga awek jurujual yang bergaun pendek, kaki panjang untuk menarik perhatian saya untuk melanggani data centre MIMOS tu tetap zero ilmu ialah, "Where is your DRC?" (Mana awak punya disaster recovery centre? Dengar betul2 ya, DRC bukan pussy macam Donald J. Trump cakap).
Soal penggendalian mala-petaka atau risiko kehilangan data hampir langsung tidak difikirkan. Itu soalan bersama jawapan2 otai2 di atas adalah lebih penting daripada 'berapa sistem pelayan atau cakera padat encik mahu beli dari saya?' Malah pernah ada sistem yang langsung entah bila buat back-up dan entah mana pergi backupnya.

Jawapan rasmi dari saya mengenai database ialah biasanya 1 dengan dwi-skema (production/dev) dan boleh buat load balancing (iklan iDempiere sikit yang menggunakan Hazelcast OSGi plugin yang di lakukan oleh arkitek projek iDempiere dari Malaysia - ingat pimpinan projek ada 2 orang Malaysia sebenarnya - saya sebagai pengasas umum dan seorang lagi Ninja tak ingin dinampak orang. Dialah yang menstabilkan migrasi kami dari Oracle ke Postgresql secara selari. Dia secara teknikal adalah ranking no.1 seluruh dunia. Saya cuma No.6. Kawan Vietnam itu No.3

Tidak bermakna saya 101% betul. Pengalaman saya terhad kepada iDempiere ERP sejak 2003 dengan datuknya iaitu Compiere, kemudian bapaknya ADempiere. Dan saya turut terlibat secara langsung dengan sistem iDempiere di Jerman, Russia, Afrika Selatan, Vietnam dan Slovakia - http://wiki.idempiere.org/en/User:Nbe222. Ini andaian sekiranya pelayan aplikasi (app server Jboss ke Tomcat ke. IDempiere kini pakai Jetty, pun hasil kerja Ninja No.1 Malaysia tersebut) adalah satu.

Sistem DB dalam iDempiere hanya satu instance dengan dwi-skema atau lebih ikut keperluan developer. Jangan sekali2 develop atas skema live production instance (ini yg dilakukan oleh ex-developer sistem hospital di Hanoi baru2 ini, memang tak masuk akal). Untuk elak kesilapan, biasakan dwi-skema secara serata dengan lain nama jelas contohnya, 'Live', 'Test'. Semasa transfer dwi-skema ikut sekali. Maknanya ada 4 kombinasi DB secara selari tetapi asas satu DB. Production server a. Live, b. Test, 2 Development server. a. Live, b. Test.

Walupun tidak ditanya tentang hardware sizing, ini tentang pelayan server atau CPU pula pentingnya dari segi data centre yang sempurna kerana IPTS akan menuju ke arah itu (ikut apa saya lihat seluruh dunia). Suasana pelayan (server environment) perlu lima:
1. Main Production Live. 2. Development. 3. Testing, 4. DRC (duduk luar kawasan bukan bawah kaki awek tu). 5. Staging dan Kuarantin semasa DRC.
Turut sama adakan UPS (bukan big ass).

Sebenarnya ini dream state saya. Jarangnya sesiapa ikut nasihat saya di atas adakan lima separate server instances. Lebih2 lagi tentang Testing server (melainkan sebuah pengguna besar di Luxemburg, memang developernya taat setia kat sifu dan memisahkan segala perubahan kod dan meta-data daripada core atau engine iDempiere - http://wiki.idempiere.org/en/AulerSipel. iDempiere pakai FitNesse. iDempiere padukan semua dalam satu CI (Continous Integration) server di sini http://jenkins.idempiere.com/

Dan tidak perlu beli yang mahal2. Cuma main server, atau kini ramai termasuk iDempiere dah selesa duduk dalam awan cloud. Yang penting password security planning, DRC dan lima pembahagian pelayan tersebut (DRC tidak boleh tempat sama secara fizikal kerana langkah keselamatan dari bencana alam. Lepas itu tengoklah siapa nak godam - lagi satu hal kerana pelajar nak tukar markah akan lakukannya).
Lagi satu amat sesuai bagi IPTA/S, ialah buatlah semua dalam open source dan libatkan pelajar pilihan sebagai aprentis. Jika jahannam boleh salahkan aprentis.