26 Nov 2011 Memilih Konfigurasi IT
Sistem adalah sebuah kesatuan siklus mekanisme pengolahan atau penanganan sejumlah obyek untuk menghasilkan sejumlah obyek baru. Obyek bisa data atau informasi, sinyal maupun prosedur. Obyek-obyek masukan, keluaran dan proses-proses pendukungnya dikelompok-kelompokan berdasarkan kategori tertentu dalam himpunan yang sering disebut entitas. Namun karena sistem adalah sebuah keatuan, maka pada dasarnya setiap obyek ada kaitannya satu sama lain, baik langsung maupun tidak langsung.
Misalnya dalam sistem pemerintahan atau kenegaraan, perpajakan dan kewarganegaraan memang jelas ada kaitan. Tetapi obyek KTP dalam entitas kewarganegaraan sepertinya tidak ada kaitan langsung dengan obyek curah hujan dalam entitas sumberdaya alam (SDA). Kaitan baru nampak misalnya manakala dalam entitas manajemen pertanian ada rencana ingin memberdayakan tingkat kesuburan tanah dan curah hujan untuk mengoptimasi produksi pertanian. Lantas bikin klasifikasi lahan pertanian berdasarkan curah hujan dan tingkat kesuburan cukup dengan query ke database SDA. Untuk menyusun metoda penyuluhan yang tepat, terlebih dulu harus tahu latarbelakang dan kualitas SDM yang bertani di lokasi tersebut. Tentu obyek KTP harus dijadikan referensi. Karena informasi lengkap tentang tingkat edukasi, pengalaman dan ketrampilan SDM berada di database KTP. Sehingga cukup dengan query ke DB KTP berdasarkan plotting lokasi lahan hasil query DB SDA di atas, akan muncul daftar nama (KTP) para pemilik lahan tersebut. Jika DB SDA dan DB KTP benar-benar siap sebagaimana mestinya, semua itu cukup dikerjakan dalam beberapa menit oleh analis pertanian. Tapi jika tidak, apa boleh buat, kembali “cara kampungan”. Mengirim petugas untuk survei lahan dan penduduk di berbagai lokasi berbulan-bulan dengan biaya besar seperti yang dilakukan di negara-negara korup tertinggal. Memang malu-maluin sih… hari gini dikit-dikit harus real data mining… alias data mining yang ngebornya ketuk pintu, bukan pake SQL … he he 🙂 Banyak belanja IT tapi manual jalan teruuus. . Ini hanya salah satu contoh. Masiih banyak ragam kaitan antar entitas dalam sebuah sistem.
Idealnya sebuah sistem memilih konfigurasi terpusat (centralized computing). Semua entitas dan semua beban komputasi terhimpun dalam satu mesin komputer. Semua kaitan logik antar obyek digarap dalam memori yang sama. Lebih cepat dan lebih sederhana ketimbang dalam mesin komputer yang berbeda yang harus melalui berbagai media. Users di manapun berada mengakses ke satu titik pusat dan mendapat layanan dari titik tersebut. Konfigurasi semacan ini sangat sederhana sehingga operasi, administrasi, perawatan maupun pengembangan mudah dan efisien. Kru cukup satu tim di pusat komputer saja.
Namun di era IT generasi awal, kapasitas komputer maupun network sangat terbatas. Mainframe pun masih belum memadahi untuk mengakomodasi pengembangan sistem informasi. Untuk mengatasinya, muncul model-model konfigurasi tersebar (distributed computing) dan terbagi.(decentralized computing). Pengguna harus memilih secara cermat model yang paling tepat sesuai karakteristik bisnisnya.
Decentralized computing solusi magel
Model terbagi (decentralized computing) adalah konfigurasi dimana fisik sistem dipecah ke dalam beberapa sistem yang lebih kecil dan beberapa entitas beban dipisah dan dibagi ke sistem-sistem kecil tersebut. Gambar sebelah mungkin menjelaskan lebih baik. Entitas A dan B di Sistem 1 dan C di Sistem 2. Pemisahan dilakukan dengan cermat untuk memilih entitas yang paling kecil korelasinya dengan entitas lain. Misalnya entitas C tidak ada paling kecil kaitannya dengan entitas lain, maka entitas C dipilih untuk dipisahkan dari A dan B. Dalam perbankan yang lazim mendesetralisasi antara aplikasi core banking dengan kartu kredit.
Memisahkan entitas dalam sebuah sistem tidak selalu mudah. Karena meskipun entitas merupakan sebuah kesatuan obyek, tetapi pada umumnya antar entitas dalam satu sistem saling berkaitan. Misalnya dalam sistem e-Gov, e-KTP merupakan sebuah entitas dan pertanahan adalah entitas yang lain. Tetapi dalam database pertanahan ada link ke database e-KTP yang dikaitkan melalui kode KTP pemilik tanah dan kode sertifikat tanah. Kaitan ini tidak boleh putus meskipun entitas pertanahan diboyong ke sistem lain.
Saking sulitnya memisahkan entitas yang saling berkaitan, kadang pihak vendor yang mengalah, terutama middleware, untuk mengisolasi keterkaitan antar entitas dengan cara membagi entitas menjadi subentitas. Contohnya CICS, sebuah middleware yang berfungsi sebagai transaction server. Memang e-KTP dan pertanahan ditangani dengan CICS yang berbeda sebagai entitas yang berbeda. Namun ketika itu kapasitas memori virtual mainframe masih 16MB per address space (24bit). Sehingga, meskipun setiap CICS menempati address space sendiri, bisa saja mengalami kekurangan memori, manakala bentangan memori yang diperlukan CICS tersebut melebihi 16MB karena beban transaksi yang terlalu besar. Dalam situasi seperti ini, pemisahan CICS tersebut ke mesin lain tidak menjawab masalah. Karena tetap saja dia memerlukan memori di atas 16MB yang tidak bisa dipenuhi oleh mesin apapun pada saat itu.
Untuk menjawab masalah tersebut, IBM mengalah membuatkan fitur dimana satu CICS bisa dibelah menjadi beberapa region sebagai subentitas. Yang dipisahkan adalah tabel-tabel pendukung yang kaitannya dengan program aplikasi tidak langsung, tetapi melalui kendali CICS. Misalnya kelompok tabel terminal dan rutin-rutin pendukungnya dipisahkan dalam terminals only region (TOR), kelompok tabel definisi file dan rutin-rutin pendukungnya dipisahkan dalam file only region (FOR), sehingga region utama hanya untuk program aplikasi atau application only region (AOR). Lantas subentitas TOR dan FOR bisa dipisahkan dari AOR masing-masing menempati betangan 16MB terpisah meskipun masih dalam mesin yang sama. Manakala kinerja mesin sudah kewalahan, maka TOR bisa dipisahkan ke mesin lain. Inilah upaya desentralisasi melalui isolasi subentitas. . Fitur-fitur ini masih ada sampai sekarang meskipun sudah tidak diperlukan lagi. .
Selain fitur TOS, FOR dan AOR pada CICS, belum pernah ada teknik desentralisasi yang sempat tercitra, apalagi berhasil. Karena pada dasarnya, sebuah sistem merupakan sebuah kesatuan mekanisme yang sulit dipisah-pisahkan.
Distributed computing solusi gagal
Model tersebar (distributed computing) adalah konfigurasi dimana fisik dan logik sistem dipecah ke dalam komputer kecil-kecil yang disebut node dan saling berkomunikasi. Karena pada dasarnya mereka adalah satu sistem, maka secara umum setiap node memuat komposisi entitas yang sama dengan ketika model terpusat. Yang berbeda adalah kapasitasnya, karena satu node hanya menanggung beban sebagian users saja. Gambar di atas mungkin menjelaskan lebih baik dengan membandingkan antara model terpusat dan model tersebar. Masing-masing memiliki formasi entitas seragam, yaitu A, B dan C. Yang beragam mungkin hanya kapasitasnya.
Konsekuansi model tersebar, formasi entitas harus seragam. Meskipun di node tertentu entitas B tidak dipakai, tetapi harus ada untuk memudahkan perawatan dan pengembangan. Tentu ada beban tambahan yang tidak ada dalam model terpusat, yaitu pendukung komunikasi. Dari sisi fisik, setiap node adalah satu sistem terpisah yang memiliki OS dan mengendalikan komunikasinya sendiri. Namun karena secara logik merupakan bagian tak terpisah dalam sebuah sistem tunggal, maka setiap entitas yang ada di setiap node tidak boleh nampak seperti pecahan. Jenis OS, middleware dan software pendukung lainnya pun harus seragam, bahkan sampai versi, rilis dan tingkat modifikasinya. .
Berbagai upaya dilakukan oleh para ilmuwan dan insinyur untuk mengintegrasikan pecahan-pecahan entitas di setiap node agar tampak tunggal secara logik. Muncul database tersebar (DRDA), metoda komputasi client/server (C/S) dll merupakan bukti upaya tersebut. Namun bahwasanya praktek tidak selalu sama dengan teori kadang ada benarnya. DRDA dan C/S belum mampu menjawab berbagai permasalahan di lapangan. Kita bisa hitung dengan jari sebelah tangan, model tersebar mana di dunia ini yang benar-benar berhasil.
Perbankan BUMN rata-rata sempat merasakan sistem tersebar dan semuanya gagal. Tidak ada satupun yang mampu bertahan lebih dari 2 tahun. Yang lucu, tidak ada satupun dari mereka yang direkomendasi oleh staff IT untuk menyelenggarakan sistem tersebar. Semuanya murni hasil kasak-kusuk antara para bos dengan vendor. BUMN jelas rugi karena harus investasi 2 kali lagi untuk kembali ke sistem terpusat. Namun tetap saja ada pihak yang diuntungkan. Silakan baca topik ini untuk menyimak sebagian kisah downsizing di perbankan BUMN.
Client/Server mengarahkan kembali ke model terpusat
Bahkan C/S itu sendiri sebenarnya tidak benar-benar sejalan dengan konsep komputasi tersebar. C/S diam-diam membelokan konsep komputasi tersebar kembali ke komputasi terpusat. C/S mengarahkan kita untuk memisahkan sumberdaya sistem seperti data dan layanan tertentu diousatkan di node tertentu yang selanjutnya disebut server. Sedangkan node yang lain dinamakan client.. Fungsinya langsung berhadapan dengan user untuk menyampaikan permintaan user, melayani proses lanjutan dan menyajikan informasi kepada user.
Makin besar skala sistem, makin besar pula kapasitas server yang diperlukan. Sistem yang semula terpusat dengan mainframe, setelah downsize ke model C/S ternyata butuh server yang skalanya mendekati mainframe tersebut. Tempo doeloe sebuah bank besar dengan IT model terpusat cukup dengan mainframe dengan real memory 1GB dan kekuatan processor 10 MIPS (< 0.5 GHz) mampu melayani seluruh cabang di sekujur Nusantara dengan response time kurang dari 2 detik. Bayangkan, seandainya aplikasinya dikonversi ke aplikasi berbasis web, mampukah server 0.5 GHz dengan RAM 1GB melayaninya? Server sebesar apakah yang diperlukan?
Tidak usah jauh-jauh survei ke berbagai user, terlalu ribet dan buang biaya. Lihat saja produk-produk komputer server sekarang ini. Memang wujudnya kompak, bahkan ada yang hanya sebesar desktop biasa. Bukankah rata-rata kapasitasnya sudah mendekati atau bahkan menyamai mainframe generasi dekade 1990an? Itu adalah pertanda bahwa arus jaman memang mengarah kembali ke model terpusat. Bukan terpusat dengan dumb terminal seperti jaman doeloe, tetapi network centric computing (NCC) yang sebenarnya C/S dengan mesin server tunggal. .Idealnya pemusatan seluruh layanan kedalam satu server. Setidaknya pemusatan setiap entitas ke satu server. Semua tujuannya adalah untuk memudahkan pelayanan kepada user dan menyederhanakan manajemen IT.
Degradasi kinerja sistem tersebar maupun terbagi
Dari sudut pandang pengguna, kelemahan paling nyata ketika sebuah sistem terpusat dirubah ke model tersebar ataupun terbagi adalah degradasi kinerja interaksi antar program. Dalam sistem terpusat, interaksi antar program dilakukan langsung dalam memori yang sama. Tekniknya bisa bermacam-macam. (1) Langsung melalui memory sharing adalah teknik yang paling mudah, tetapi memerlukan otoritas akses common segment. (2) Langsung melalui cross memory services, merupakan teknik yang paling aman, tetapi selain perlu otoritas untuk mengexekusi instruksi privileged MVCP dan MVCS, juga hanya bisa dilakukan dengan assembly.
Cara yang palling mudah dan portable adalah (3) melalui network programming. Dikatakan portable karena teknik ini.tidak membedakan program akan dijalankan di komputer yang sama atau berbeda. Dibanding teknik memory sharing maupun cross memory services, kinerja network programming tentu kalah. Karena harus melalui tahapan sebagaimana telah diatur oleh protokol. Meskipin demikian, karena jalan dalam host yang sama, semua proses hanya berlangsung dalam memori. Untuk SNA, tidak ada PU-PU session. VTAM langsung menganggap sesi fisik berhasil. Gambar sebelah mungkin menjelaskan lebih baik.
Sedangkan untuk TCP/IP lebih extrim lagi. Jika program-program yang berinteraksi berada dalam OS yang sama, API membelokkannya sebagai memory sharing. Sehingga tidak ada stack pun interaksi tetap jalan. Tetapi jika program-program yang berinteraksi berada dalam guest OS yang berbeda dalam satu komputer yang dioperasikan dengan z/VM, maka z/VM menyediakan hypersocket yang menembus dinding setiap virtual machine. Hypersocket sebenarnya memori yang direkayasa untuk tampil sebagai network media bagi virtual machine. Sehingga meskipun proses komunikasi dilakukan sampai ke sesi fisik, namun sebenarnya semua proses berjalan dalam memori yang sama. Tentu saja kinerjanya jauh lebih hebat dibandingkan benar-benar interkasi antar komputer.
Namun ketika sistem dirombak ke model tersebar atau terbagi, interaksi antar program tidak ada jalan lain selain network programming. Sesi fisik dan transmisi melalui network media tidak bisa dihindarkan. Sehingga proses I/O dengan network media baik di pihak sumber maupun pihak sasaran yang tentu dampak overheadnya cukup signifikan. Gambar sebelah mengkin menjelaskan lebih baik.
Sehebat apapun kapasitas network, tentu kinerjanya tidak akan sebanding dengan memori. Oleh karena itu konversi sistem dari model terpusat menjadi tersebar maupun terbagi hanya sepadan untuk dilakukan manakala tidak ada solusi lain ketika kapasitas maximum server pusat tidak lagi memadahi untuk menopang beban. Kasus ini hanya mungkin terjadi sebelum generasi 64-bit.
Virtualisasi mengarahkan kembali ke model terpusat
Tentang virtualisasi lebih jauh dapat disimak di beberapa artikel berikut ini:
- Mainframe zEnterprise cara jitu beternak server
- Capacity planning untuk virtualisasi server
- Virtualisasi dengan z/VM makin heboh
Teknologi virtualisasi hari ini sudah semakin canggih. Tidak lagi melulu kejituan software, melainkan hardware pun sudah dipersiapkan untuk divirtualisasi. Lihat gambar sebelah dan bandingkan dengan gambar di atas. Sistem dengan 3 entitas, A, B dan C yang tersebar dalam 3 node pada gambar di atas, hari ini bisa diringkus dalam satu host pada gambar sebelah. Users tidak merasakan bedanya karena di mata mereka tidak ada perubahan. Mereka tidak tahu bahwa yang mereka hadapi ilusi.
Nah… pertanyannya, kenapa muncul virtualisasi???
Rasanya logika awam pun tak akan keseleo menjawabnya. Orang capek dan blepotan dengan distributed system maupun decentralized system. Yang semula centralized system merasa bersalah menggantinya dengan sistem tersebar maupun desentral. Yang memang dari awal sudah tidak terpusat juga merasa rugi. Kenapa demikian?
Tentu saja!!! Sistem tersebar maupun terbagi tidak sekedar mahal saja, tetapi juga ribet merawat dan mengembangkannya. Butuh kru yang besar dan/atau mobilitas tinggi untuk menanganinya. Jika ada perubahan, tidak hanya ketangkasan kru saja yang menjadi hambatan, tetapi juga prosedurnya. Karena meskipun perawatan dan pengembangan ditangani oleh kru pusat, namun operasinya, setiap node punya otoritas.
Teknologi virtualisasi ini tidak sekedar mengarahkan sistem tersebar maupun terbagi untuk kembali terpusat. Bahkan beragam sistem yang tidak ada kaitan satu sama lain pun bisa di-hosting terhimpun secara fisik terpusat. Ini sangat merupakan kesempatan bagi bisnis hosting yang besar.
Cloud computing
Cloud computing adalah model komputasi baru? Istilahnya memang baru! Mungkin idenya perokok kali ya? he he 🙂 Karena jaman doeloe umumnya sysprog atau systems engineer yang tukang ngoprek jeroan OS biasanya bekerja sambil merokok. Lebih-lebih ketika debugging, berjam-jam menelusuri logik curah memori (memoty dump) yang selalu dalam notasi hexadesimal tercetak di atas kertas bersambung (continues form), mata melotot, muka berminyak, satu tangan pegang pensil atau stabilo corat-coret dan tangan yang lain menjepit rokok. Kadang tampak bureng karena pandangan terhalang asap rokok. Naah giliran mereka menjadi arsitek IT dan menemukan model komputasi yang berorientasi layanan lantas mereka namai komputasi asap eh awan he he … guyon 🙂
Cloud computing adalah model komputasi dimana IT adalah penyedia layanan tanpa user harus tahu komputer mana yang sedang melayani. Jadi sepertinya komputer-komputer itu berada di balik awan. Ide paling awal adalah hadirnya session manager pada jaringan SNA, dimana seseorang dari dumb terminal 3270 bisa online dengan aplikasi apa saja di host mana saja selama saling interkoneksi. Tentu otoritas akses harus terpenuhi untuk berinteraksi dengan setiap aplikasi. User tidak perlu tahu di host mana aplikasi berada, cukup memanggil namanya dengan VTAM command LOGON APPLID(nama-aplikasi). Terminal lantas sesi dengan aplikasi yang dipanggil. Tentu hanya berlaku untuk nama-nama yang unik. Untuk nama yang tidak unik, maka nama host harus disertakan.
Setelah hadir internet, setiap komputer yang terkoneksi bisa berinteraksi dengan aplikasi apa saja di server mana saja selama memiliki otoritas. Bedanya, dalam jaringan internet, kita harus menunjuk server dengan alamat atau nama IP dan menunjuk aplikasi dengan nomor port. Untuk sesama aplikasi berbasis web, cukup dibikinkan halaman depan sebagai index dan user bisa pilih aplikasi link yang tercantum disana untuk menuju ke aplikasi yang diinginkan. Lah itu mah biasa donk 🙂 Internet memang begitu. Lantas istimewanya cloud computing dimana? Yang jelas istilah baru pasti kedengaran keren, lumayan buat ngecap di depan calon korban yang bodoh.
Sebenarnya cloud computing adalah konsep bisnisnya. Kita bisa bikin sebuah sistem dimana semua aplikasi kita ditanam di sejumlah server yang disediakan oleh pihak ketiga (penyedia hosting). Idealnya, dengan cloud computing, kita tidak lagi mikirin merancang dan belanja infrastruktur, baik di tahap awal maupun tahap pengembangan selanjutnya. Kita juga tidak perlu memiliki SDM teknik selain programmer untuk membangun aplikasi yang kita perlukan. Tentunya di balik awan, para pihak ketiga telah siap dengan lapaknya masing-masing. Ada lapak yang menyediakan server siap pakai dan ada yang menyediakan jaringan komunikasi siap kring. Tentu dengan krunya yang handal. Kuncinya tinggal apakah kita yakin menanamkan aplikasi kita ke lapak-lapak tersebut? Namanya bisnis selama ada yang jual dan ada yang beli, jadilah.
Apakah semua jenis aplikasi bisa ditanam dalam cloud computing? Yang direkomendasikan sih hanya aplikasi yang berbasis web. Namun jika yang buka lapak di balik awan niat dan jitu, seharusnya semua jenis aplikasi online bisa. Bisa disini dalam artinya jalan lho! Tidak lebih dari itu. Termasuk apkikasi legacy yang non-web pun bisa. Yang penting ada lapak yang mau menyediakan server yang cocok dan kru SDM yang memadahi, pasti bisa. Misalnya untuk aplikasi transaksi CICS yang masih berbasis dumb terminal 3270, lapak harus menyediakan server z/OS dan kru operator dan system support yang handal. Untuk user disediakan sarana akses telnet 3270 atau client program yang dirancang untuk menggantikan telnet 3270 bergaya GUI.
Memilih konfigurasi untuk e-Gov negara kesatuan
e-Gov adalah sistem pemerintahan yang di-IT-kan. Bicara soal konfigurasi IT hari ini, apapun sistemnya pasti cocok dengan model terpusat. Tak terkecuali e-Gov, Kendala kapasitas dan kualitas komunikasi sudah lama terlewati. Artinya, manakala model terpusat dipilih, maka keberhasilan sudah berada pada arah yang sama. Terlebih untuk negara kesatuan yang sistem pemerintahannya satu format.
Namun pekerjaan apapun biasanya tergantung kapabilitas dan kualitas arsitek dan/atau komandannya. Untuk proyek e-Giov mungkin saja konfigurasi terpusat tak terpikirkan sama sekali karena yang dia lihat sehari-hari hanya laptop dimejanya atau PC di warnet.
Masih mending jika yang dipilih model decentralized. Artinya setiap entitas sudah terpusat di server masing-masing. Kita bisa meniru konsep cloud computing. Ada lembaga khusus yang seolah-olah buka lapak di balik awan menyediakan server dengan infrastruktur dan seluruh komponen pendukungnya, serta kru SDM yang memadahi. Lantas semua server setiap entitas di-hosted disana. Lembaga pemilik entitas cukup menyediakan tim pengembang aplikasi saja.
Lembaga pemilik lapak yang cerdas harus jitu menjaga agar awannya tidak menjadi cumulus apa lagi cumulonimbus. Mending memanfaatkan teknologi virtualisasi seperti gambar sebelah. Semua server adalah virtual server yang ditanam dalam satu sistem mainframe. Fisiknya akan jauh lebih sederhana dan manajemennya juga mudah. Tidak hanya aplikasi berbasis web saja yang bisa ditanam disana, melainkan aplikasi yang bersifat mission-critical pun masuk. Karena aplikasi semacam ini dalam e-Gov pasti ada.
Setelah berada dalam satu rumah, selanjutnya tinggal bagaimana membenahi agar setiap entitas yang berkatian (langsung atau tidak) benar-benar bisa dikaitkan dalam program aplikasi. Jika semua sudah benah, suatu saat bisa disentralisasikan ke dalam satu logik sistem untuk meningkatkan efisiensi. Atau setidaknya ada beberapa virtual server yang bisa dikonvergensikan menjadi satu virtual server.
Yang sedih jika yang dipilih model distributed. Membangun aplikasinya sama dengan model terpusat. Tetapi implementasinya harus clone berulang setiap node yang mengharuskan keseragaman pondasi setiap node dijaga ketat. Lebih parah lagi jika sebarannya terlalu luas, misalnya node per kabupaten/kota. Bisa jadi kelas tertentu IPv4 tidak cukup untuk menyusun networknya. Dalam operasi sehari-hari, energinya dihabiskan di lalulintas data network. Kelak pada generasi mendatang manakala sudah mengharuskan disentralisasikan, investasi dan volume pekerjaannya terlalu besar.
Namun demikian, baik model desentral maupun tersebar, bila aplikasi sudah dibangun tetapi infrastruktur belum sempat digelar, masih ada cara untuk menyelamatkannya, yaitu dengan virtualisasi. Secara logik tetap desentral atau tersebar, tetapi semua node di-hosted dalam mesin virtual. Sehingga fisiknya terpusat. Setidaknya mengurangi overhead lalulintas data network dan ribetnya perawatan. Kelak pada generasi mendatang manakala sudah mengharuskan disentralisasikan, investasi dan volume pekerjaannya tidak sebesar perubahan fisik.
Yang paling cilaka adalah manakala yang dipilih model tak terdefinisi. Setiap kabupaten/kota membangun siistem sendiri-sendiri dengan rancangannya sendiri layaknya sebuah negara terpisah. Kelak di akhir hari hanya akan menyusahkan anak-cucu. Karena yang terwujud adalah semacam kumpulan e-Gov banyak negara. Itupun kalo ada wujudnya. Sungguh menyedihkan dan memalukan. Ibarat bus dikemudikan tukang becak. Pasti tidak akan mencapai tujuan.
Overhead lalulintas data network dan ribetnya perawatan bisa diatasi dengan virtualisasi. Tetapi goal-nya sebagai e-Gov tetap tidak akan tercapai, kecuali jika kriteria goal didefinisikan sendiri untuk pembenaran. Yang jelas goal para vendor tercapai, baik penyedia produk maupun layanan. .
Memilih konfigurasi untuk e-Gov negara serikat
Negara serikat adalah himpunan negara-negara bagian. Tiap negara bagian memiliki otonomi yang cukup besar yang memungkinkan menentukan sebagian format subpemerintahannya sendiri yang unik. Semua itu tergantung kesepakatan antar negara bagian menekala menyusun konstitusi bersama. Sehingga sistem pemerintahannya meskipun tunggal tetapi berjenjang dan setiap subsistem tidak seragam. Proyeksinya dalam e-Gov tergantung kejituan arsiteknya.
Ada arsitek yang mampu menyeragamkan menjadi sistem tunggal terpusat demi kesederhanaan proses. Karena kadang apa yang dianggap perbedaan hanya istilah. Inti formatnya sama. Misalnya, di negara bagian A adalah kadipaten yang dipimpin oleh seorang adipati yang membawahi beberapa wedana. Sedangkan negara bagian B adalah pakuwon yang dipimpin oleh akuwu yang membawahi beberapa demang. Tatanan pemerintahan kadipaten A dan pakuwon B sebenarnya sangat mirip. Maka untuk kesederhanaan sistem, arsitek bisa menyeragamkan sebagian atau seluruh entitas kedua negara bagian tersebut. Sehingga konfigurasinya menjadi mirip e-Gov negara kesatuan. Namun sosialisasinya cukup berat, baik kepada rakyat mauipun aparat.
Ada pula yang memilih memproyeksikan apa adanya demi kemudahan pemakainya. Sosialisasinya lebih mudah. Tetapi volume pekerjaan pembangunannya lebih besar, karena entitas lokalnya lebih beragam.
Yang memilih proyeksi apa adanya, memungkinkan ada keragaman entitas di setiap negara bagian seperti tampak pada gambar di atas. A, B dan C merupakan entitas federal yang berlaku umum. Sedangkan E, F dan G hanya berlaku lokal di negara bagian 1. P dan Q hanya berlaku di negara bagian 2. X, Y dan Z hanya berlaku di negara bagian 3. Bila konfigurasi fisiknya memilih terpusat, maka yang benar-benar terpusat hanya entitas pemerintah federal. Sedangkan pemerintah setiap nagara bagian menjadi semacam sistem terpisah yang terkoneksi dengan sistem federasi pusat.
Jika konfigurasi fisiknya memilih model tersebar, maka setiap node ada bagian yang seragam meruapakan pecahan dari sistem tersebar, dan ada bagian lain hanya berlaku lokal seperti pada gambar sebelah. Dalam praktek, baik model tersebar maupun terpusat (semi), bisa divirtualisasikan supaya fisiknya terpusat.
Topik-topik terkait
No Comments