Seluk-beluk Membangun dan Mengelola e-Gov

11 Jun 2012 Seluk-beluk Membangun dan Mengelola e-Gov

Pada tulisan 14 Nov 2011 telah digambarkan bahwa e-Gov adalah IT berskala besar membentuk sebuah sistem tunggal yang mencakup semua layanan sistem informasi, administrasi dan komputasi seluruh lembaga pemerintahan sebuah negara untuk mewujudkan layanan tuntas kepada seluruh warganegara, kapan saja, jam berapa saja, dimana saja. e-Gov merupakan hasil reformasi dari IT pemerintahan konvensional.

Sistem pemerintahan pada dasarnya adalah sistem tunggal. Hanya saja masing-masing sektor memiliki kewenangan sesuai tugas dan tanggungjawabnya, sehingga satu sama lain tidak saling terbuka. Konsolidasi dan koordinasinya berada di tingkat kepala pemerintahan. Tentu konsekuensinya banyak sekali redundancy yang tak terhindarkan, baik data maupun proses. Seseorang sudah didata di Dagri (kecamatan) untuk KTP, masih harus menyetor data yang sama di Polres untuk SIM, masih juga memberikan informasi yang sama di perpajakan, BPS dll. Sebidang lahan sudah didata di BPN, masih didata lagi di irigasi (PU) dan juga didata di perpajakan, pertanian dll. Semua itu wajar untuk mendukung pola kerja tiap sektor yang masih manual. Resikonya tentu banyak, seperti satu orang punya banyak KTP, harga tanah tidak sesuai dengan NJOP dsb. Semua itu sangat tergantung mentalitas semua manusia terlibat disana, baik rakyat, pejabat maupun pelaksana proses.

Giliran memasuki era IT, setiap sektor merasa perlu membangun IT untuk kepentingannya sendiri. Mereka paham bahwa IT mampu mendongkrak kecepatan dan ketepatan kerja. Namun kebanyakan pemahamannya hanya sampai disitu. Maka tidak aneh jika Kemendagri lantas bikin sistem e-KTP, sementara POLRI juga merencanakan bikin INAFIS, dan KPU bikin voter registry (VR). Bisa jadi sektor lain juga ikutan bikin entah apa lagi. Semua berlomba menggelar IT tanpa memikirkan intergrasi lintas sektoral untuk mewujudkan e-Gov yang benar. Mereka tahu bahwa sistem pemerintahan adalah sistem tunggal. Jangankan kita yang negara kesatuan. Sedangkan negara serikat saja tetap menganggap pemerintahnya sistem tunggal, setidaknya di tingkat federal. Tetapi tidak menyadari hakikat sistem tunggal, terutama dari sudut pandang e-Gov. Karena mereka tidak menyadari bahwa redundancy dan duplikasi obyek informasi yang ada selama ini hanyalah sekedar konsekuensi sistem manual. Dikiranya memang begitulah aturan main sebuah pemerintahan. Yang penting didukung UU atau peraturan. Hanya itu!.

Bahkan pemda kabupaten dan kota dengan dalih otonomi daerah juga bikin e-Gov sendiri-sendiri mulai dari masterplan hingga tuntas terwujud sebuah sistem. Yang jelas jika 206 negara di dunia sudah bikin e-Gov, maka di dunia ini sekurang-kurangnya akan ada 675 e-Gov, yang 205 e-Gov milik negara lain dan selebihnya adalah e-Gov milik pemkab/pemkot disini 🙂 Lho… kita kan “memang beda”. “Kita disini nggak bisa disamakan dengan mereka disana”. Itulah suara-suara yang sering terdengar ketika berbincang soal e-Gov.

Parahnya lagi, e-Gov tersebar per pemkab/pemkot tersebut bukan sekedar konfigurasi tersebar, melainkan benar-benar multi sistem yang beragam dan terpisah-pisah. Di sebuah milis e-Gov saya sempat bertanya; “apa yang harus dilakukan dengan e-Gov nya jika satu pemkab mekar menjadi dua?”. Ada yang menjawab lucu; “nggak masalah, sementara pemkab yang baru e-Gov nya nebeng dulu”. Saya komentar lagi; “Bagus, memang sebenarnya setiap pemkab/pemkot bisa saling tebeng, karena negeri ini negara kesatuan, tentu format resmi pemerintahannya seragam. Dengan demikian, kelak mudah diintegrasikan menjadi e-Gov sistem tunggal”. Saya pikir mereka terjebak dengan logika tersebut untuk digiring ke rel yang benar. Eh ternyata tidak! Katanya nebeng untuk sementara. Nantinya pemkab yang baru bikin e-Gov baru yang beda lagi. He he he … “bancakan” 😀

Jangan menjadi tumbal bisnis IT

Apa tidak ada yang mengingatkan? Seperti biasa… ketidaktahuan, kekakuan UU/peraturan dan ego sektoral campuraduk dengan berbagai kepentingan lain. Negara kita adalah negara besar. Tentu saja belanja IT-nya besar pula. Para vendor dan bisnis IT jelas sangat diuntungkan. Andaikan ada pihak yang sadar pun, tidak akan bisa berbuat apapun jika sudah berhadapan dengan UU/peraturan. Malah jika memaksakan, yang benar bisa menjadi salah secara yuridis, karena melanggar UU/peraturan. Itulah misterinya bisnis IT, mendapatkan tumbal tanpa menyalahi hukum.

Pembangunan e-Gov harus ditangani oleh pakarnya, setidaknya pakar IT, yaitu orang memahami teori IT dan sudah memeiliki sejumlah pengalaman sukses. Bukan sekedar pernah bikin website atau menyelesaikan desertasi. Melainkan mensukseskan berbagai proyek pembangunan “IT beneran”. Syukur-syukur pernah ikutan dalam proyek dapur IT di negara lain yang e-Gov nya terbukti berhasil. Kesempatan semacam itu memang langka. Mungkin dengan menjadi support systems engineer (SE) pada vendor yang produknya dipakai disana, setidaknya bisa bersentuh langsung dengan dapur IT disana dan berbincang dengan para SE lokal disana.

Hanya penjelasan orang-orang exekutif ataupun humas dalam seminar maupun artikel dan mengamati penampilan web saja, sering kali menyesatkan. Nggak usah jauh-jauh soal e-Gov yang komplex… Kita sudah pernah dapat pelajaran serupa 15 tahun silam. Bos-bos bank plat merah pulang seminar langsung rame-rame menggelar revolusi downsizing yang menelan ratusan milyar hanya untuk menikmati aksi SCO Unix on PC kurang dari 2 tahun. Pedih rasanya menjadi tumbal zero sum game bisnis IT.

e-Gov vs IT Pemerintahan konvensional

Istilah e-Gov muncul setidaknya 2 dekade setelah Amrik dan beberapa negara maju lainnya meng-IT-kan sistem pemerintahannya. Yang menghadirkan istilah e-Gov pun mereka pula. Namun e-Gov bukan sekedar istilah. e-Gov adalah suatu bentuk revolusi mental birokrasi pemerintah. Ada pergeseran paradigma yang cukup signifikan, khususnya dalam pelayanannya pada warganegara (G2C), dari transaction oriented ke service oriented. Artinya, di sisi arsitektur sistem bergeser dari sistem berbasis transaksi ke SOA. Lebih dalam lagi, server-nya pun bergeser dari transaction server (semisal CICS) ke SOAP (semisal HTTP).

Barangkali bagi yang sudah belajar IT tidak asing dengan istilah-istilah tersebut. Namun kadang pengertian SOA hanya dikaitkan dengan fase rekayasa software saja. Sehingga sering tersesat pada checklist yang sempit. Dikiranya kalo sudah melibatkan semua teknologi dan onderdil SOA dalam membangun sistem pastilah terwujud sebuah sistem yang service-oriented.

Sedangkan SOA dalam konteks e-Gov, yang terpenting derajat ke-SOA-an e-Gov itu sendiri dalam mewujudkan fungsi utamanya dalam melayani warganegara (G2C) dan bisnis (G2B), serta interaksi antara lembaga pemerintah (G2G). (1) Apa artinya portal Pertanahan direkayasa serba SOA jika untuk melihat tanah-tanah yang saya miliki harus meng-entry setiap nomor sertifikatnya? (2) Apa artinya portal Perpajakan dibangun serba SOA jika untuk melihat rincian pajak harus meng-entry NPWP dengan benar? (3) Apa artinya e-Gov dibangun ber-SOA-ria jika untuk kirim jatah bulanan anak (yang sedang kuliah), saya harus masuk ke portal e-banking bank tertentu dan harus ingat nomor rekening anak saya untuk di-entry-kan sebagai penerima? Kondisi sistem semacam ini dinamakan transaction-based system. Meskipun jeroannya serba SOA compliant, tetapi e-Gov semacam ini sebenarnya belum mengikuti paradigma service-oriented system, dengan kata lain, IT pemerintahan yang masih trandisional alias konvensional, alias bukan e-Gov 🙂

Ciri khas lain transaction-based system adalah perbedaan gerbang masuk antara pelayan dan yang dilayani. Silakan simak gambar sebelah. Jika anda punya e-toko dengan Zencart, Opencart atau aplikasi e-store lainnya, berarti anda memiliki transaction-based system. Anda login dengan lorong yang berbeda dengan pembeli, dan ketika anda sedang login di lorong anda, anda tidak bisa membeli dagangan anda. Untuk membeli dagangan sendiri, anda harus signup dan login sebagai pembeli. Terlepas jeroannya serba SOA, preekkk… Sistem semacam ini bukan service-oriented system.

e-Gov, harus service-oriented system. Contoh (1) dan (2) di atas adalah fungsi G2C. Mestinya terlepas apapun teknologi yang ada di jeroannya, sekali login ke e-Gov dengan identitas warganegara (WNid), saya menjadi e-citizen. Selanjutnya saya bisa melihat (1) detil seluruh tanah yang saya miliki, cukup klak-klik menuju halaman Pertanahan. Tidak perlu memasukkan nomor sertifikat. Justru saya bisa melihat seluruh nomor sertifikat tanah milik saya. Demikian pula dengan pajak, (2) cukup mengikuti navigasi ke halaman Perpajakan, saya bisa melihat rincian pajak dan NPWP saya pribadi maupun usaha-usaha yang terkait dengan nama (WNid) saya.

Contoh (3) adalah fungsi G2B, yaitu layanan bisnis. e-Gov berinteraksi dengan bisnis (e-business), baik untuk kepentingan administrasi dan korespondensi antara pemerintah dan dunia bisnis, maupun menjadi jembatan interaksi antara e-citizen dengan e-business. Justru yang kedua ini, kedua pihak e-business lebih diuntungkan. Pihak e-Gov bisa memantau langsung pajak transaksinya. Pihak e-business merasa mendapat jalur paling aman, karena WNid tidak mungkin palsu. Kembali kepada contoh (3), sekali saya login e-Gov, berarti saya menjadi e-citizen. Jika bank saya sudah G2B, maka setiap menuju ke portal bank tersebut, otomatis saya login ke e-bankingnya. Katakanlah saya lupa nomor rekening anak saya, saya bisa telusur dari data keluarga dan karena saya orangtuanya dan anak saya masih dalam tanggungjawab saya, maka saya berwenang (authorized) untuk melihat detil record kewarganegaraan anak saya termasuk nomor rekening yang dia miliki.

Ciri khas lain service-based system, tidak ada perbedaan gerbang masuk antara pelayan dan yang dilayani. Silakan simak gambar di atas. e-Gov termasuk kategori ini. Semua harus login menggunakan WNid, dan selanjutnya berperan sebagai e-citizen. Semua memiliki hak dan kewenangan yang sama sebagai e-citizen. Perbedaannya adalah kewenangannya dalam mengakses aplikasi-aplikasi pelayanan pemerintah tertentu berdasarkan status jabatan (dan pangkat) yang tertera dalam record kewarganegaraan.

Tahu bedanya e-store dengan e-Gov? Pembeli (user) di e-store tidak perlu transparansi yang mendalam. Yang penting dia naksir barangnya dan ada duit, lantas dia beli dan harus dapat barang, titik. Setelah itu mungkin dia akan lupakan. Sedangkan e-citizen dalam e-Gov sangat perlu transparansi yang mendalam. Jika di halaman Pertanahan tiba-tiba perubahan data sertifikat yang berubah, anda ingin dikonfirmasi terlebih dulu. Jika anda tidak setuju, anda bisa mengangkatnya menjadi kasus hukum dan pihak hukum bisa melihat WNid aparat Pertanahan yang melakukan update yang tidak anda setujui.

e-Gov sistem tunggal vs semangat otonomi daerah?

Sering terungkap sejumlah pendapat dalam berbagai forum diskusi sebuah pembenaran kenapa tiap pemkab dan pemkot bikin e-Gov sendiri-sendiri. Konon karena alasan otonomi daerah. Entah mengacu teladan yang mana, otonomi daerah mendorong untuk bikin e-Gov sendiri-sendiri. Apakah tiap daerah menginginkan privasi exklusif dalam sistem pemerintahannya? Jika demikian, lantas apanya yang harus exklusif tertutup? Apa sistem keuangannya biar pusat tidak tahu? Ataukah diam-diam mau bikin tatanan pemerintahan sendiri? Dan yang paling penting … apakah konstitusi kita mendukung exklusivitas tiap daerah?

Padahal jika kita tengok dua jiran kita yang e-Gov nya sudah mapan, Australia dan Malaysia, pasti kita tahu bahwa mereka bukan sekedar otonomi daerah. Mereka justru gabungan dari negara-negara bagian yang tentunya otonominya sampai pada tingkat tatanan pemerintahan dan hukum yang tidak seragam. Namun toh e-Gov mereka sistem tunggal. Mungkin karena disana otonomi tidak ada kaitannya dengan exklusivitas maupun privasi dalam e-Gov. Tidak ada informasi yang harus disembunyikan. Lagipula pembagian otoritas kan bukan rahasia. Mereka memilih menanggulangi keberagaman format menjadi seseragam mungkin dari sisi IT demi mewujudkan e-Gov yang memadahi.

Faktor utama e-Gov adalah IT. Faktor utama IT adalah program komputer (software). Faktor utama program komputer adalah logik. Dan… logika sangat luwes, bisa dibawa kemana saja sesuai kecerdasan perancangnya. Meskipun demikian, teknologi apapun selalu mengutamakan kemudahan pemakaian dan kesederhanaan instalasi, pengoperasian, perawatan dan biaya. Bahkan sementara orang ada yang mengatakan keep it simple stupid (kiss). Dengan pertimbangan itulah, para pakar yang cerdas berupaya keras memanfaatkan keluwesan logika untuk mengatasi perbedaan format pemerintahan di setiap negara bagian guna mewujudkan sebuah sistem tunggal. Sedangkan kita yang negara kesatuan yang tentunya berformat tunggal malah berupaya mengurainya menjadi beragam untuk dijadikan alasan membangun e-Gov sendiri-sendiri. Jadi kalau dipikir-pikir, kita ini kelewat cerdas.

Diperlukan Komisi e-Gov dengan kewenangan penuh dari Kepala Pemerintah

Dalam konteks IT pemerintahan, redundancy ataupun duplikasi antar sektor bukan kesalahan. Tetapi dalam konteks e-Gov, jelas merupakan kegagalan. Mengingat, e-Gov bukan sekedar sistem IT pemerintahan. e-Gov adalah sebuah pembaharuan sistem IT pemerintahan yang semula fungsinya hanya sekedar membantu kerja pemerintah berkembang membantu rakyat mendapatkan layanan pemerintah. Dengan e-Gov, rakyat bisa mendapatkan layanan pemerintah 24 jam sehari, 7 hari semingga dimanapun dia berada. Dengan kata lain, e-Gov adalah sebuah sistem pemerintahan swalayan.

Dalam rangka mewujudkan fungsi e-Gov tersebut, mau tidak mau seluruh IT pemerintahan di seluruh sektor harus diintegrasikan menjadi sebuah sistem tunggal, lantas disambung dengan sejumlah web-based front-end untuk memberi kemudahan bagi rakyat mengaksesnya. Kalimat sederhana tersebut sebenarnya harus dibayar dengan seabreg pekerjaan yang cukup komplex, antara lain meniadakan redundancy maupun duplikasi obyek (data maupun proses) apapun guna menyederhanakan proses keseluruhan. Mengingat e-Gov merupakan sistem terbuka untuk publik dimana kondisi peak-nya pasti jauh di atas kondisi semula dan sangat fluktuatif.

Perombakan IT pemerintahan konvensional menjadi e-Gov sangat memungkinkan pembangunan ulang sejumlah aplikasi yang tentunya sangat beresiko. Diperlukan koordinasi yang solid antar tim antar sektor untuk menjamin integrasi dan pengembangan/perubahan berjalan mulus. Koordinasi solid ini selanjutnya menjadi tim khusus (task-force) dan harus diberi kewenangan khusus pula dari kepala pemerintahan guna menembus wilayah sensitif di setiap sektor serta menetralisir ego sektoral. Sebut saja Komisi e-Gov dan bekerja setara kementerian. Banyak negara yang menempatkan Komisi e-Gov sebegai Kementerian IT dan e-Gov.

Semua gagasan, rancana, rancangan dan pembangunan IT di seluruh sektor pemerintahan merupakan wewenang dan tanggungjawab Komisi e-Gov. Obyek apa saja di sektor mana saja selama terkait dengan IT dan/atau e-Gov harus terbuka untuk Komisi e-Gov. Selain untuk menjamin berlangsungnya proses integrasi, juga untuk menjamin terlaksananya pembangunan komponen-komponen e-Gov yang berjangka panjang melampaui satu atau lebih perioda pemerintahan 5-tahunan. Bahkan, bila perlu, masa bakti pimpinan dan pejabat Komisi e-Gov, tidak mengikuti perioda pemerintahan 5-tahunan guna menetralisir kecenderungan memprioritaskan pekerjaan jangka pendek. Hal ini mengingat pembangunan e-Gov umumnya memerlukan waktu panjang (lebih dari 10 tahun) dan banyak pekerjaan panjang yang justru harus diprioritaskan.

Strategi integrasi dari IT konvensional menjadi e-Gov

Membangun e-Gov kita sebenarnya tidak serumit gambaran di atas. Karena IT pemerintahan kita masih belum mapan. Boleh dibilang, e-Gov kita berangkat dari nol, sehingga tidak banyak pekerjaan merombak. Namun demikian, mengingat para aparat dan pejabat kita belum terbiasa dengan IT, harus ada pekerjaan extra Komisi e-Gov untuk memberi penjelasan kepada mereka tentang misi dan visi e-Gov.

Langkah selanjutnya adalah mengintegrasikan IT yang sudah ada. Meskipun tidak banyak, pekerjaan merombak sejumlah aplikasi untuk saling berintegrasi tidak mudah. Untuk memudahkan tim perombak Komisi e-Gov melakukan pembedahan, terlebih dulu me-rehost seluruh IT yang ada ke dalam satu wadah menggunakan teknologi virtualisasi mesin. Selama proses perombakan dan integrasi sedang berlangsung di virtual machine, operasi sehari-hari tetap berjalan seperti semula di real machine. Cara ini sekaligus menjamin IT aslinya (real machine) tetap berjalan tanpa gangguan sedikit pun.

Awalnya kita koneksikan satu sama lain dengan virtual LAN. LAN tanpa ujud yang berkecepatan memori. Sementara di sisi lain, Tim Perumus Data Komisi e-Gov telah menyiapkan sejumlah DBMS baku pondasi e-Gov di virtual machine terpisah yang dijalankan dengan OS yang akan dijadikan platform baku di dapur e-Gov. Himpunan DBMS berjalan dengan dummy content sekedar untuk uji fungsi dan uji sistem saja.

Sementara Tim Integrator Komisi e-Gov membedah setiap aplikasi di setiap virtual machine guna memilah mana data yang harus bersumber dari DBMS pondasi dan mana yang lokal sektoral. Lantas setiap aplikasi dirombak untuk mengikuti aturan akses tersebut. Langkah ini juga disebut tahap penyederhanaan logika, dimana redundancy dan duplikasi obyek dieliminir sebersih mungkin. Tidak hanya kontens, tetapi juga penamaan maupun pengalamatan obyek tidak boleh ada duplikasi. Disinilah perlunya setiap sistem harus open system compliant, untuk menjamin kemampuan data sharing antar sistem.

Langkah selanjutnya adalah menyederhanakan sistem. Idealnya semua aplikasi masuk dalam satu virtual machine dan lantas di-native-kan menjadi real machine seperti gambar sebelah ini. Tidak lagi ada console sendiri-sendiri di setiap sektor. I/O overhead juga dieliminasi karena semua data menjadi lokal.

Namun demikian, jika aplikasi-aplikasi tersebut tidak berasal dari platform sistem yang sama, kadang masih ada kendala lain meskipun sama-sama open system compliant. Di tahap inilah semua kendala dipecahkan guna menyederhanakan sistem. Aplikasi-aplikasi yang portable didahulukan.

Sedangkan aplikasi yang platform-specific (jika ada) prioritas kedua. Sementara bertahan dalam virtual machine hingga ada solusi yang tepat. Dalam situasi seperti ini, tidak ada virtual machine yang menjadi real machine kecuali diboyong ke hardware lain. Namun menambah hardware berarti menambah komplexitas dan divergen dengan upaya integrasi. Sebenarnya tidak masalah jika virtualisasi mesin dilakukan dengan z/VM, karena z/VM mampu menyelenggarakan preferred guest V=R maupun V=F, dimana overhead virtualisasi ditekan nyaris nol.

Integrasi vs Single point of failure

Bicara soal single point of failure sangat diperlukan pengalaman berhadapan dengan sistem “IT beneran”. Karena jika dibahas hanya dari sisi teori, ibarat catur bisa remis. Sementara itu, membangun e-Gov tentu akan berhadapan dengan dilema ini. Di satu sisi, dapur e-Gov merupakan integrasi dari seluruh IT sektoral. Namanya juga integrasi, tentu tidak sekedar mengkaitkan obyek-obyek yang ada secara logik saja. Idealnya juga menggabungkan semua obyek dalam satu wadah. Selain menyederhanakan banyak hal, memang ada sejumlah kasus yang integrasinya hanya bisa dilakukan jika sebagian obyeknya berada dalam satu wadah.

Misalnya sharing data untuk jenis-jenis aplikasi yang mission-critical. Selain proteksinya harus maksimal, kecepatannya juga terukur. Sharing data akan menjadi kendala yang beresiko tinggi. Aplikasi akan jatuh-bangun karena gangguan keamanan maupun timeout. Jika kondisi seperti ini dipaksakan, manajemen dan kru IT hanya akan disibukkan oleh masalah yang tidak perlu terjadi jika mereka berada dalam satu wadah. Artinya, misi menghindari single point of failure sia-sia karena justru menghadirkan lebih banyak failure.

Di sisi lain, menggabungkan semua obyek dalam satu wadah akan menuju ke single point of failure. Namun sesuai misi dan fungsi e-Gov, integrasi tidak mungkin dielakkan. Untuk itu, mesti disiasati secermat mungkin dengan memilih platform yang tepat untuk menyusun mekanisme disaster recovery yang cerdas, misalnya GDPS. Lagi pula yang perlu diingat, apa artinya menghindari single point of failure jika satu failure yang lain ikutan failure gara-gara logiknya sudah saling terkait karena sudah integral. Ibarat orang ngambil jalan tikus untuk menghindari macet tapi malah kejebak banjir. Hal-hal seperti ini harus ditimbang extra saksama oleh para pakar dalam Komisi e-Gov jangan sampai terjebak pada dilema yang tidak perlu.

Pondasi harus diprioritaskan meski perlu waktu panjang

Awalnya saya menyimak e-KTP, saya kira akan menjadi identitas tunggal warganegara (WN) yang mencakup semua informasi yang terkait dengan individu WN. Sehingga database (DB) e-KTP adalah DB WN yang merupakan tulangpunggung e-Gov kita. Namun dengan munculnya gagasan INAFIS di Polri dan proyek pembangunan voter registry (VR) di KPU yang sama-sama berbasis DB WN, lantas anggapan di atas buyar. Kenapa tidak menunggu DBMS e-KTP rampung? Meskipun tidak harus menunggu kontens DB, tapi membangun aplikasi DB hanya bisa dilakukan setelah DBMS rampung meskipun dengan kontens dummy. Fakta yang terjadi menunjukkan bahwa INAFIS maupun VR bukan aplikasi DB e-KTP. Berarti DB e-KTP bukan DB WN. Sehingga baik e-KTP, INAFIS maupun VR berada di layer yang sama, yaitu sama-sama aplikasi DB WN yang tentunya harus menunggu DBMS WN.

Anehnya, saya belum pernah dengar adanya DBMS WN. Jangan-jangan saya yang kuper. Tapi lebih aneh lagi, e-KTP dan VR melakukan koleksi kontens untuk DB nya masing-masing. Apakah masing-masing akan bikin DBMS sendiri? Redundant donk? Apakah DBMSnya sudah jadi? Super aneh lagi jika DBMS belum jadi sudah koleksi kontens.

Oke lah, terlepas apa yang sebenarnya terjadi, saya sudah kadung beranggapan DB e-KTP bukan DB WN seperti yang menjadi tulangpunggung e-Gov pada umumnya. Maka untuk selanjutnya dalam tulisan ini saya anggap ada DB WN dan e-KTP adalah salah satu aplikasinya, seperti tampak pada gambar sebelah. Saya tidak peduli apa yang ada sebenarnya saat ini. Namun menurut saya, gambar sebelah menunjukkan rancangan yang benar dan yang seharusnya dilakukan.

Salah satu fungsi utama e-Gov, bahkan yang paling utama adalah layanan government-to-citizen (G2C) yang intinya menggelar hubungan swalayan terhadap e-Ciitizen atau e-warganegara (e-WN). Tidaklah patut disebut e-Gov sebelum mewujudkan fungsi ini. Kunci utama terwujudnya fungsi G2C adalah:

1. Seluruh warganegara terdidik dan memiliki sarana untuk menjadi e-WN
2. Infrasrtuktur ICT yang memungkinkan setiap warganegara (e-WN) mengakses e-Gov
3. DBMS WN yang memadahi dari sudut pandang kualitas, aksesabilitas, kapasitas, skalabilitas, keamanan, kinerja dan dukungan teknis.

Tiga kunci di atas perlu waktu panjang dan biaya yang besar untuk membangunnya. Namun karena merupakan komponen dasar pondasi e-Gov, maka mau tidak mau harus diprioritaskan paling utama. Sangat tergantung kecerdasan para pejabat perencana dalam Komisi e-Gov untuk menyusun rencana dan jadwal pembangunannya.

Hemat saya, DBMS WN digarap dulu. Pekerjaan ini mencakup pemilihan platform server, OS, DB engine atau middleware serta menyusun konfigurasi sistemnya, perancangan dan pembangunan DBMS yang memadahi. Mengingat DBMS WN merupakan unsur utama pondasi e-Gov dan bersifat mission-critical, maka pemilihan platform server, OS, DB engine atau middleware harus berdasarkan studi kelayakan yang maksimal yang bisa dipertanggungjawabkan, baik secara ilmiah maupun hukum. Sama sekali tidak boleh sekedar selera atau pengaruh popularitas. Rancang-bangun DBMS WN juga harus ditangani secara cermat dengan mempertimbangkan perkembangan e-Gov jangka panjang agar tidak terjadi tambal-sulam di tengah perjalanannya kelak. Disinilah perlunya SDM berpengalaman yang sangat mumpuni terlibat dalam Komisi e-Gov, tidak hanya memajang panjangnya rentetan gelar akademis.

Selanjutnya dibangun sejumlah aplikasi di atas DBMS WN, misalnya e-KTP (Dagri), INAFIS (Polri), VR (KPU) dll. Meskipun aplikasi-aplikasi tersebut berbasis database WN (DB WN), tidak berarti DB WN harus bermuatan data beneran. DB WN cukup diisi dummy content untuk sekedar menjalankan dan menguji fungsi aplikasi-aplikasi tersebut. .Bila perlu DBMS lain dan rombongan aplikasinya, terutama yang kaitannya dengan DBMS WN paling dekat.

Sementara itu, tim lain dalam Komisi e-Gov harus mulai membangun infrastruktur ICT segera setelah memutuskan konfigurasi sistem, tanpa harus menunggu DBMS WN kelar. Sehingga 2 kelompok proyek tersebut berjalan paralel. Keduanya sama-sama memakan waktu yang cukup panjang. Infrastruktur kemungkinan lebih panjang mengingat di negeri kita masih banyak daerah tertinggal yang sulit dijangkau ICT.

Pendidikan praktis IT dan e-Gov kepada seluruh WN bisa dimulai setelah DBMS WN dan sejumlah aplikasinya siap. Tentu pelaksanaannya bergulir merambat mengikuti pengembangan infrastruktur hingga mencapai ke seluruh pelosok Tanah Air. Pelatihan juga digelar untuk para siswa, mahasiswa, PNS, TNI/Polri, pejabat, legislator, aparat hukum, para menteri bahkan presidan tanpa kecuali, karena mereka semua adalah sesama WN. Pelatihan bisa dilakukan dengan mengakses langsung semua aplikasi yang sudah siap meskipun hanya berisi dummy content. Justru dengan e-Gov yang masih kosong tersebut, setiap WN berkesempatan berganti-ganti peran secara dummy sebagai rakyat, pejabat tertentu, aparatur tertentu dan sebagainya.

Transparansi e-Gov

Berbeda dengan IT pemerintajan konvensional, e-Gov lebih menjamin transparansi dalam segala hal. Dalam sistem IT pemerintahan konvensional, pintu akses dibedakan sesuai peran individu dalam pemerintahan. Mirip pada sistem perbankan, dimana pintu akses untuk nasabah tidak sama dengan teller dan berbeda lagi dengan staff IT. Dalam IT pemerintahan konvensional ada pintu akses untuk WN dan ada pintu akses untuk aparatur pemerintah. Sesama aparatur pemerintah juga dibedakan atas tugasnya. Polisi punya pintu akses sendiri. Petugas pertanahan punya pintu akses sendiri. Demikian pula militer, staf pemerintah dll. Pejabat biasanya gaptek dan cukup nuding anakbuahnya untuk melakukan transaksi tertentu di wilayah otoritasnya.

Pintu akses berupa logonid tiap aplikasi dan tidak selalu berkaitan dengan identitas sah WN. Otoritas akses melekat langsung pada logonid tiap aplikasi, seperti gambar di atas. Aplikasi appl-1 menyediakan logonid untuk para petugasnya, mungkin dengan otoritas beragam atau seragam. Demikian pula aplikasi appl-2 dan appl-3. Siapa saja yang menjadi petugas akan mendapatkan logonid. Ketika petugas lama digantikan dengan petugas baru, password harus segera diganti untuk mencegah petugas lama login dan melakukan hal-hal di luar tanggungjawabnya. Pola pertanggungjawabannya mengikuti kebijakan pengelola aplikasi masing-masing yang kadang tidak saling koordinasi.

Misalnya petugas SIM memiliki logonid khusus ke aplikasi SIM. Petugas KTP memiliki logonid khusus ke aplikasi KTP yang mungkin berada di sistem IT terpisah. Wajar jika alamat yang tercantum di SIM tidak selalu sama dengan yang di KTP. Apalagi jika logonid khusus tersebut dipakai secara bergantian oleh petugas yang berbeda. Perlu tahapan teknis yang cukup rumit untuk mengetahui siapa yang melakukan transaksi tertentu. Terlebih jika database-nya tersebar di berbagai wilayah, sangat memungkinkan orang yang sama memiliki beberapa KTP dan/atau SIM, dengan nama yang sama atau berbeda.

e-Gov, sesuai paradigmanya harus didisain sedemikian rupa untuk menjamin transparansi dari sisi WN maupun pemerintah. Untuk itu, semua akses harus berbasis e-WN yang merepresentasikan identitas WN yang sah (WNid). Mengakses fungsi apapun dalam e-Gov harus didahului dengan login e-WN. Otoritas melekat pada record DB WN sesuai indikator status jabatan/fungsinya (jobid) dalam pemerintahan. Jobid berupa rujukan (pointer atau soft-token) yang menunjuk ke record DB Personalia dimana sang WN menjabat, atau 0 jika bukan pejabat pemerintah.

Istilah soft-token atau token saja, sering digunakan dalam systems programming sebagai pengganti pointer. Biasanya terdiri dari indikator dan argumen yang dengan formula tertentu akan menjadi pointer bersyarat. Dalam hal ini soft-token cukup berupa 1 digit indikator lembaga dimana si WN bekerja diikuti nomor induk/pokok kepegawaian.

Ketika seseorang login e-WN, kewenangan akan diberikan e-Gov sesuai jobid-nya di DB WN, seperti tayangan gambar sebelah. Seseorang yang menjabat untuk mengoperasikan aplikasi appl-1 tidak perlu logonid khusus seperti pada IT konvensional. e-WN dia otomatis berwenang atas appl-1. Karena jobid pada DB WN-nya menunjuk ke DB kepersonaliaan di lembaga tempat dia bekerja yang mencakup kode atau indikator pangkat dan jabatannya. Berdasarkan kode inilah otoritas akses atas sejumlah aplikasi diatur.

Aplikasi bisa berdampak update terhadap obyek tertentu yang terkait dengan satu atau beberapa atau bahkan semua e-WN. Demi transparansi, tidak ada kewenangan mutlak untuk e-WN, meskipun dia presiden. Setiap mekanisme update terhadap obyek, selalu memerlukan konfirmasi dari pihak tertentu. Misalnya, jika anda polisi lalulintas, jobid di DB WN menunjuk ke DB Polri. Sesuai kode pangkat dan jabatan, anda berwenang menjalankan aplikasi polantas. Dengan kewenangan tersebut, anda bisa saja menuding si Pulan telah melakukan pelanggaran lalulintas melalui aplikasi polantas. Tudingan berdampak penjadwalan persidangan lantas untuk Pulan disertai peringatan yang akan muncul setiap kali si Pulan login e-WN, juga undangan resmi kepada Pulan melalui email resmi e-Gov untuk Pulan. Sebelum hakim ketuk palu, peringatan (warning) di layar e-WN Pulan akan tetap muncul.

Jika dalam sidang, si Pulan memang bersalah, maka anda sebagai polantas mendapat kredit yang tercatat di DB WN anda. Makin banyak kredit yang anda dapatkan makin cepat anda naik pangkat. Namun sebaliknya jika ternyata dalam sidang anda tidak bisa membuktikan Pulan bersalah, maka catatan kredit anda di DB WN akan berkurang.

Contoh lain, jika anda pejabat SLTA yang bertugas memasukkan nilai rapot ke DB SNMPTN, maka jobid anda di DB WN menunjuk DB PNS dan berdasarkan kode pangkat/jabatan disana anda berwenang menjalankan aplikasi SNMPTN untuk meng-entry rapot tiap siswa. Katakanlah sistem pendidikan SLTA ke bawah belum di-IT-kan. Tentu tidak ada jaminan anda akan memasukkan data rapot 100% akurat. Oleh karena itu, demi transparansi, setiap siswa mendapat pemberitahuan nilai rapot yang telah dimasukkan ke DB SNMPTN dan diminta mengkonfirmasi untuk pengesahan. Setiap kali siswa login e-WN, pemberitahuan selalu muncul hingga botton SETUJU diklik. Bagi siswa yang merasa nilainya dijatuhkan, tentu tidak mau mengklik SETUJU sampai anda mengkoreksinya dengan nilai yang sebenarnya. Anda tidak bisa lagi bermain-main dengan pendaftaran SNMPTN untuk merugikan siswa baik tidak sengaja maupun sengaja menyingkirkan para siswa yang nilainya melampaui nilai siswa yang anda restui seperti yang pernah terjadi melalui web SNMPTN pada tahun 2011. Anda juga tidak bisa menutup tugas anda sampai seluruh siswa mengklik tombol SETUJU.

Model kewenangan yang terbagi sesuai pangkat dan jabatan dan terkait langsung dengan WNid seperti ini merupakan salah satu misi utama revolusi e-Gov dalam meniadakan pemusatan kewenangan pada logonid tertentu yang lazim dalam IT pemerintahan konvensional. Dengan demikian, transparan lebih dijamin. Terlebih manakala seorang petugas menjalankan aplikasi (dalam otoritasnya) yang berefek update pada informasi tertentu milik orang lain (WNid lain),

Upaya mensupremasikan transparansi tidak hanya sebatas teknologi e-Gov. Semasa sosialisasi dan pelatihan, transparansi dipraktekan secara simulasi. Semasa pelatihan, tentu IT e-Gov sudah mencapai stadium kerampungan yang sudah memenuhi syarat untuk memasuki fase produksi. Tetapi semua DBnya belum ada isinya. Isinya masih dummy content. Dengan isi bohongan tersebut, selain berperan sebagai WN biasa (rakyat), setiap peserta latihan diberi kesempatan berperan sebagai pejabat negara (lurah, camat, polisi, hakim, bupati hingga menteri dan presiden) dan mencoba memoraktekan tugas dan kewenangan melalui e-WNnya. Dengan demikian tidak ada lagi rasa kecurigaan bahwa seorang pejabat bisa melakukan kezaliman melalui e-Gov. Memang merancang dan membangun e-Gov memerlukan kecerdasan dan kreativitas lebih dari sekedar orang IT yang hebat.

Koleksi kontens – tahap awal produksi

Semua praktisi IT pasti tahu, memasukkan data atau kontens hanya bisa dilakukan setelah sistem dinyatakan memasuki fase produksi. Orang awam pun mestinya tahu. Lihat saja Facebook, Linkedin, Yahoo dll… Apakah kita pernah kirim data, foto dll ke posko-posko FB? Apakah para petugas Linkedin mendatangi kita untuk koleksi kontens? Setahu saya, Facebook, Linkedin, Yahoo dll muncul dulu di internet, lantas kita signup membuat akun. Setelah itu baru mengisikan data-data (foto, note dll) kesana menggunakan sarana yang mereka sediakan. Artinya, mereka masuk fase produksi dulu, baru koleksi kontens. Tidak hanya FB, Linkedin dan Yahoo saja yang demikian. IT perbankan, asuransi dll .. semua IT memang harus demikian, kecuali IT yang dikelola oleh orang-orang belum memahami IT 🙂

Kenapa demiikian? Alasannya klasik… untuk memasuki fase produksi, sistem harus mengalami seabreg uji kualitas, mulai dari setiap detil fungsinya hingga keseluruhan sistem dan finalnya adalah user acceptance test (UAT). Konsekuensinya, sistem yang dinyatakan lulus dan masuk produksi, tidak boleh ada perubahan lagi meskipun satu bit. Tidak ada lagi superuser untuk para systems engineer (SE). Yang ada hanya user, operator dan admin. Admin pun hanya sebatas bermain parameter yang tidak sensitif sesuai kebijakan sekuriti yang telah ditetapkan SE semasa di fase pembangunan dan tidak bisa dirubah lagi karena akun SE-nya sudah dinonaktifkan. Mungkin ada yang bertanya-tanya .. lhoh… bagaimana jika suatu saat ada maintenance, misalnya memasang patches?

Si penanya pasti orang awam IT. Jawabannya, semua update dilakukan di development system dan harus melalui sejumlah tahapan pengujian yang ketat. Setelah dinyatakan lulus, baru di-cloned ke sistem produksi. Sehingga tidak ada satupun makluk yang diperbolehkan main slonong boy di sistem produksi. Kontens maupun obyek terproteksi total dan hanya user yang berhak saja yang bisa mengaksesnya. Dengan demikian, sistem yang sudah produksi bisa dibilang sistem yang kualitas dan keamanannya sudah dijamin.

e-Gov pun harus mengikuti tradisi ini. Masuk fase produksi dulu, baru memulai tahap koleksi kontens. Perbedaannya dengan FB, Yahoo, Linkedin atau e-banking dll menjadi keunikan e-Gov, antara lain:

• Membuat akun (signup) e-WN di e-Gov adalah wajib bagi setiap WN.
• Ada informasi akun / e-WN yang sudah predefined oleh pemerintah dan WN tidak boleh ngarang sendiri, misalnya WNid (mungkin = NIK atau SIN).
• Ada kaitan logik yang dikawal hukum antar WNid, misalnya antara anak dan ortu dan/atau wali, dan antara suami dan (para) isteri.
• Ada informasi akun / e-WN yang mendapatkannya harus dengan bantuan dan pengawasan pemerintah, yaitu data biometrik.
• Ada informasi di luar akun yang hanya pemerintah yang berwenang meng-entry-nya, misalnya informasi pertanahan, SDA, perpajakan dll.
• Untuk tujuan transparansi, semua aplikasi data-entry untuk mengisi DB hanya bisa dilakukan melalui login e-WN yang memiliki kewenangan atas aplikasi tersebut.
• Kewenangan setiap e-WN tercantum dalam kode atau token jobid WN tersebut di DB WN yang merujuk ke DB kepersonaliaan lembaga pemerintah (PNS, TNI, Polri dll) atau lembaga negara (Presiden, DPR, MA dll) dimana WN tersebut menjabat.

Batch dan Otomasi

Dengan e-Gov, penilaian kinerja aparat tidak lagi mutlak ditentukan oleh bosnya. Melainkan secara otomatis berdasarkan absensi yang tersambung langsung dengan DB kepersonaliaan terkait dan banyaknya pekerjaan yang diselesaikan yang tercermin dari banyaknya transaksi yang dilakukannya melalui login e-WN, serta banyaknya pelanggaran yang tercatat dalam data kriminalitas Polri maupun Peradilan. Bosnya hanya dimintai konfirmasi melalui panel e-WN si bos yang akan outstanding beberapa hari. Jika jangka waktu tersebut kelewat maka dianggap setuju, tapi berdampak pada nilai negatif kinerja sang bos. Nilai yang didapat bisa dilihat oleh si aparat ybs maupun bosnya. Dampaknya pada kenaikan gaji juga otomatis setelah disetujui sang bos.

Bila si bos mengklik tombol TIDAK SETUJU, maka si aparat akan diminta konfirmasi menerima atau mengusut ke atasan si bos yang juga akan outstanding beberapa hari. Jika jangka waktu tersebut kelewat maka dianggap setuju dan nilai kinerja berubah menjadi nol. Jika si aparat memilih mengusut, maka outstanding request di panel e-WN atasan sang bos dan akan muncul mekanisme serupa antara sang bos dengan atasannya yang tentunya akan mempengaruhi kinerja sang bos jika tidak mampu mempertahankan argumentasinya. Namun tidak akan menjadi rumit karena jenjang birokrasi sudah jauh lebih sederhana.

Kenaikan pangkat juga tidak lagi ribet harus bikin usulan disertai berbagai lampiran pendukung melalui korespondensi yang makan waktu dan bertele-tele. Melainkan otomatis berdasarkan akumulasi nilai kinerja dan panjangnya masa kerja. Bahkan kenaikan pangkat tidak perlu lagi konfirmasi dari bos, karena nilai kinerja yang didapat sudah mencerminkan filter yang ketat. Namun dampaknya pada pergeseran kewenangan ada yang memerlukan konfirmasi persetujuan dari bos atau dari pihak lain sesuai jenis kewenangan yang akan didapatnya.

Perhitungan pajak bumi dan bangunan juga tidak lagi hanya dengan perkiraan seperti sekarang yang kadang lucu. Melainkan dinamik disesuaikan dengan perkembangan tata ruang, situasi ekonomi dan produktivitas kewilayahan berkat terintegrasinya sistem informasi seluruh sektor. Update dinamik tersebut dilakukan secara otomatis setiap hari guna mendapatkan nilai rata-rata harian yang lebih representatif.

Selain penilaian kinerja, kenaikan, perhitungan pajak dinamik, masih ada puluhan bahkan ratusan kasus lain yang harus diproses otomatis. Pendek kata, semua informasi yang bersifat variable memerlukan proses perubahan. Sementara itu, tidak setiap perubahan harus menunggu picu transaksi online dari e-WN tertentu. Oleh karena itu, demi transparansi, harus ada proses yang berjalan otomatis, mulai dari yang harian, mingguan, bulanan, tahunan, maupun menganut siklus tertentu, misalnya pada hari-hari tertentu atau tanggal-tanggal tertentu. Proses-proses semacam ini lazim dinamakan batch dan otoritasnya (terpaksa) tidak mengikut e-WN manapun. Operasinya dilakukan dengan sarana penjadwal otomatik untuk menjamin ketepatan dan menghindari kesalahan manusia. Juga untuk menghindarkan meberian kewenangan kepada seseorang untuk menjalankan operasi batch. Satu-satunya yang berwenang hanya penjadwal otomatik.

Himpunan proses batch inilah yang merupakan komponen paling mission-critical. Karena tiap proses berjalan sedemikian cepat, satu-sama lain ada kadang harus mengikuti urutan tertentu (schedule flow) yang tidak boleh salah. Sehingga jika ada proses yang mandeg tidak normal akibat kesalahan apapun akan menjadi pemicu kesalahan berikutnya dan menyebabkan informasi menjadi brantakan fatal.

Mengelola sistem “mission-critical”

Mengelola sistem mission-critical sangat berbeda dengan sistem biasa, terlebih dengan warnet :). Mula-mula dipersiapkan model disaster recovery (DR) yang memadahi dan teruji. Tim penguji datang secara mendadak dan sekonyong-konyong memutus saluran listrik pada CPU atau salah satu atau beberapa mesin lainnya tanpa kompromi. Lantas diperiksa apakah ada kerusakan? Apakah sistem jatuh? Adakah proses yang jatuh? Adakah data yang hilang? Jika ada kerusakan, berapa lama memulihkannya? Jika sistem jatuh, berapa lama membangkitkannya kembali? Jika ada proses yang jatuh, berapa lama menjalankannya kembali? Jika ada data yang hilang, berapa lama me-restore-nya kembali? Apakah data yang hilang bisa ditemukan kembali setelah restore? Dan…. masih banyak lagi yang harus dilakukan…..

Sistem yang mission-critical compliant menyediakan model DR yang canggih dan lebih murah. Beberapa server yang masing-masing didukung dengan himpunan disk dengan mirroring yang terbentang jarak jauh digabung menjadi satu konfigurasi GDPS, dimana semuanya menjadi bagian dari sistem produksi dan satu sama lain saling backup secara dinamik. Pembagian beban akan dijaga untuk selalu setimbang. Jika salah satu server jatuh, maka bebannya otomatis berpindah secara merata ke server lainnya.

Kedua, dipersiapkan pengamanan yang extra ketat. Bukan semata-mata menghindari pembobolan obyek saja. Lebih jauh, dampaknya pada kerusakan obyek yang bisa menjadi bola salju yang menggerus obyek-obyek lain yang berkaitan. Oleh karena itu sistem pengamanan tidak hanya mengandalkan produk-produk sekuriti yang berbasis kecerdikan logika saja. Melainkan juga harus mengandalkan state operasi tidak mungkin ditembus dengan kecerdikan logika.

Ketiga, kinerja sistem dirancang dan dipersiapkan sedemikian rupa untuk terhindar dari situasi kebuntuan (deadlock). Misalnya proses A, B dan C bersama-sama mengakses data ABC. Gara-gara B bermasalah, maka A dan C jadi terimbas dan ikut macet. Lebih parahnya lagi, setelah A, B dan C mandeg, saluran I/O yang menuju disk dimana data ABC berada juga menjadi macet sehingga mempengaruhi seluruh akses yang menuju disk tersebut. Boot ulang biasanya penyelesaian yang paling lazim. Namun perlu diingat bahwa e-Gov adalah sistem 23×7. Sehingga jangan harap bisa menjadwalkan boot ulang dengan mudah.

Untuk menghidari kebuntuan, harus disusun prioritas akses yang tepat antara A, B dan C terhadap ABC. Namun prioritas akses tidak cukup diproyeksikan dengan prioritas I/O. Percuma saja I/O diprioritaskan ke B jika data ABC sudah kadung diblok oleh A gara-gara alokasi durasi CPU time A lebih panjang dari B. Tetap saja B harus menunggu A. Sehingga prioritas layanan CPU pun harus dirancang dengan seksama sesuai tingkat layanan atau service level (SL) yang kita rencanakan.

Sistem yang mission-critical compliant selalu menyediakan sarana tuning ketimbang sekedar autotune. Gambar sebelah menampilkan sarana tuning pada sistem z/OS yang dinamakan WLM. Alokasi layanan CPU tidak hanya sekedar menyusun dispatching priority (DP) mana yang harus didahulukan ketika lebih dari satu task antri memasuki lingkaran exekusi. Admin juga diberi kesempatan merancang 3 macam goal kinerja setiap task, yaitu (1) response time untuk durasi tertentu, (2) kecepatan relatif (menggambarkan maximum penundaan yang bisa diterima ketika task siap memasuki exekusi) untuk durasi tertentu dan (3) discretionary atau autotune. Susunan prioritas dan goal setting tersebut dinyatakan dalam parameter OS dengan nilai awal tertentu dan dikoreksi setiap saat sesuai dengan tingkat pencapaiannya yang dilaporkan oleh performance monitoring tool. Pada gambar sebelah dicontohkan bagaimana cara ngeset goal kecepatan relatif 92% di kolom velocity untuk task atau workload AK1. Di importance diset 1 yang berarti dispatching priority AK1 termasuk jajaran tertinggi.

Dalam merancang susunan prioritas dan goal setting selain memperhatikan SL setiap task juga logik operasinya di tingkat OS. Misalnya task A, B dan C sama-sama mengakses data ABC. Susunan prioritas dan goal setting A, B dan C ditentukan berdasarkan SL yang direncanakan. Tetapi jangan lupa, DB engine untuk data ABC harus mendapat prioritas di atas A, B dan C. Jangan sampai yang dilayani lebih diprioritaskan ketimbang yang melayani, bisa menyebabkan deadlock.

Prioritas dan goal setting tersebut juga bisa ditujukan kepada enclave atau gugus beberapa task yang saling berkaitan atau serumpun. Mengelompokkan beban sistem dalam enclave menjadi sangat penting jika kita memilih konfigrasi GDPS. Karena task akan didistribusi keseluruh server berdasarkan kesetimbangan beban. Sehingga tidak ada jaminan task A di server yang mana dan task B di server yang mana. Dengan mengelompokkan sejumlah task tertentu dalam satu enclave, prioritas dan goal setting yang telah ditentukan akan dibawa ke server manapun yang mengexekusinya.

Topik-topik terkait

1. Menyimak e-KTP
2. e-Gov untuk Mencegah Kejahatan
3. Mainframe – Solusi Paling Jitu untuk e-Gov
4. Agromatika – Jembatan ke Nusantara Hari Esok
5. Agromatika – Konten Utama e-Gov Nusantara
6. Merenungi e-Global
7. Misteri Seputar IT
8. Menyimak e-Gov jiran
9. Memilih Konfigurasi IT
10. Mengenal Seputar SDM IT
11. e-Gov Menjadikan Pemerintah Swalayan Tuntas
12. Awan Cumulonimbus Hadir di Jagat IT