Strategi Penentuan SaaS atau PaaS untuk Penyelenggaraan Aplikasi di Daerah
16
Pernahkah Anda mengunjungi suatu situs pemerintah daerah dengan SiLo data pada layanan IaaS menggunakan Tld domain *.go.id namun antar mukanya judi slot, gacor, atau konten NSFW (Not Safe for Work)? Atau melakukan pencarian jejak hack pada muatan website dan mendapati bahwa artikel mengandung kata kunci hacked by? Lalu ketika dicari siapa pengelola teknisnya, tidak ada Keputusan atau Surat Tugas yang jelas? Ini adalah permasalahan klasik digitalisasi kriminal siber (cyber crime) yang secara normatif penyelesaiannya adalah secara hukum, melalui aparat penegak hukum.
Ditinjau dari luaran, maka ini adalah perkara teknis, dan yang paling bertanggungjawab adalah pelaku. Namun jika dilihat dari sisi yang lebih ekstensif, maka ini adalah tentang digital leadership.
Bilamana suatu permasalahan keamanan itu terjadi sekali, dapat dikatakan itu insiden. Namun jika insiden itu terjadi berkali-kali dengan pola yang sama, maka itu dapat dikatakan problem.
Workflow penanganan insiden biasanya berawal dari laporan di help desk. Permasalahan repetitif lumrahnya akan selesai di help desk karena customer services memiliki akses ke dokumentasi atau katalog pengetahuan. Sampai di sini, belum diperlukan eskalasi permasalahan ke manajerial atau top level management.
Insiden yang tidak dapat diselesaikan di help desk, lumrahnya akan diteruskan ke tim teknis. Dari tim teknis akan dilakukan identifikasi permasalahan dan troubleshot.
Sebagaimana diterangkan sebelumnya, insiden yang terjadi secara terus-menerus dapat dikatakan sebagai problem. Jika insiden dilakukan eskalasi hanya sekitaran help desk dan tim teknis, maka problem harus dilakukan eskalasi ke manajerial. Mengapa? Karena penyelesaian problem adalah keputusan atau kebijakan. Jika tidak ada sikap (keputusan atau kebijakan) maka yang terjadi adalah looping atas insiden. Insiden akan terjadi secara terus-menerus baik cepat ataupun lambat.
Ilustrasi di atas, didapati kita petakan dalam kerangka: people, process dan technology.
Dari sisi People, maka pertanyaannya tidak akan keluar dari dua hal, yakni siapa penanggungjawab penyelenggaraan dan siapa penanggungjawab teknis atas sistem. Penanggungjawab penyelenggaraan dapat dipastikan adalah pejabat. Pada pemerintahan, bisa pejabat struktural/manajerial entah kepala bidang, kepala bagian/sub bagian, sekretaris, dsb. Baik mengerti atau tidak mengerti cara menyelesaikannya, yang paling dituju atas suatu pertanggungjawaban permasalahan secara normatif pasti seorang ‘kepala’. Sementara pertanggungjawaban penanganan teknis lumrahnya adalah IT Support/Technical Support/Pengelola Teknis/Teknisi atau istilah lain yang mengacu kepada penanganan hal-hal teknis atas sistem. Maka atas ilustrasi tersebut, tidak didapatkan keterangan penanggungjawab penyelenggaraan maupun keterangan penanggungjawab pengelola teknis. Sebab tidak ada SK/ST.
Dari sisi Process, kita bisa petakan hal-hal yang mendasari proses yang terjadi. Di pemerintahan, lumrahnya proses itu akan mengacu kepada SOP atau orang IT menyebutnya BPMN (Business Process Modeling and Notation). SOP lumrahnya mengacu kepada suatu task modular atas tugas dan fungsi suatu Perangkat atau Unit Organisasi yang mana ini dapat ditemukan pada dokumen kebijakan semisal SOTK. Jadi bicara proses maka ini sebenarnya hanya akan mengacu kepada ketersediaan SOP dan SOTK. Baik SOP yang berdiri sendiri, tertuang dalam standar pelayanan minimal/publik maupun lainnya. Baik SOTK yang tersedia pada JDIH kabupaten/kota, provinsi atau pemerintah pusat. Dari ilustrasi di atas, tidak diterangkan hal berkenaan nama instansi sehingga tidak dapat ditelusuri SOTK-nya. Sebab tidak terang SOTK-nya maka tidak dapat di-tracing pula SOP-nya.
Dari sisi Technology, didapati bahwa layanan yang digunakan adalah SiLo data pada IaaS.
Diketahui leading sector teknologi informasi pada pemerintahan Indonesia bagian manapun akan mengacu kepada Dinas Komunikasi dan Informatika. Maka ‘kambing hitam’ atas pertanggungjawaban pertama-tama akan mengacu kepada kepala Diskominfo. Dari sana akan didapati keterangan layanan yang bermasalah itu Probis mana (Unor mana). Hanya pada penyelenggaraan sistem yang tidak jelas, masalah pelemparan pertanggungjawaban itu akan terjadi. Dari leading sector teknologi, akan mengarahkan pada siapa yang punya Probis. Dari yang punya Probis, biasanya justru merupakan pihak yang paling tidak tau apa itu Probis? Itu kan bahasa orang IT? IT itu bukannya Diskominfo? Coba datang ke Diskominfo, arsitektur pemerintah digital coba konsultasikan ke Ortal. Maka siapapun yang mencoba menyelesaikan permasalahan penyelenggaraan layanan yang tidak memiliki kematangan, akan menjadi seperti bola ping-pong. Akan berputar-putar pada konsultasi dan koordinasi dengan Diskominfo, Ortal dan Perangkat/Unor yang punya Probis.
Di situlah pangkal permasalahannya. Unor yang punya Probis, tidak ada pengelola teknis TI/Aplikasi Informatika yang ditetapkan dalam suatu Keputusan/Surat Tugas. Sehingga tidak akan ada kejelasan pertanggungjawaban teknis maupun kejelasan pertanggungjawaban penyelenggaraan sarana pra sarana berkenaan ‘atap’ Probis yang bersangkutan.
Lumrahnya kondisi seperti itu akan mengembalikan semua ke Diskominfo. Mencoba melakukan permintaan untuk pembuatan/penyelenggaraan SiLo data. Bilamana diamini, maka pintu masalah baru justru ada, terbuka dan lebih besar. Mengapa? Ini seperti masuk ke habitat buaya yang jika masuk, susah atau tidak bisa keluar. Karena penyelenggaraan aplikasi dilakukan bukan oleh entitas yang punya probisnya. Mungkin pada beberapa waktu di awal semuanya terasa indah. Ada event untuk launching, pesta, makan-makan, hidangan yang enak, ucapan selamat, dst. Namun ketika muncul satu saja permasalahan kecil yang ditemukan operator web atau visitor, urusannya menjadi memanjang dan melebar, sebab? Birokrasi.
Mulai dari operator web yang mengalami kendala satu, dua, tiga kali atau lebih. Berkonsultasi kepada atasan langsung. Atasan langsung mengarahkan ke luar dinas. Ke luar dinas jika tertib aturan maka menggunakan surat pengantar. Surat pengantar berarti tata naskah. Tata naskah berarti datang kea tau mencari konseptor. Dari konseptor konsultasi muatan tata naskah ke atasan langsung, konsultasi EYD dan tata naskah ke bagian umum/persuratan. Jika ada revisi, maka revisi terlebih dahulu. Selesai revisi, konsultasikan ulang, jika ada revisi, maka revisi lagi, terjadi looping sampai takah selesai, itupun jika atasan responsible untuk fungsi ketersediaan dan penelaahan. Selesai ditelaah, maka diparaf, selesai diparaf maka datang ke kepala, jika kepala responsible untuk fungsi ketersediaan dan penelaahan, maka dokumen dapat ditandatangani, jika tidak maka urusan pending dan kembali di lain waktu. Selesai ditandatangani maka buat Salinan. Asli diarsipkan dan Salinan dilegalisir (stampel). Itu jika petugas ada/tersedia untuk fungsi legalisir. Maka jadilah surat pengantar untuk berkunjung lintas OPD.
Salinan surat pengantar berlegalisir diantar ke OPD tujuan, dilakukan disposisi atau eskalasi secara langsung ke kepala Unor terkait. Dari Kepala Unor biasanya akan mengarahkan ke PIC tertentu atau musyawarah bersama pihak-pihak yang terkait. Selesai musyawarah, permasalahan teknis akan mengantri pada IT Support.
Setelah sekian lama mengantri, maka tibalah hal teknis yang perlu dieksekusi. Ternyata permasalahan hanya dengan pengubahan satu dua baris kode program atau satu dua file saja yang tidak memakan banyak waktu.
Bisa dibayangkan jika setiap masalah teknis kecil DevOps siklusnya harus sepanjang itu dari Unor Probis ke Unor layanan hosting? Ini jauh dari efektif, jauh dari efisien. Lalu dengan gaya seperti ini ingin mengacu kepada user/citizen-centric? Ini jauh dari logis. Melayani kebutuhan kecil atas DevOps sendiri, masih menggantungkan segalanya ke luar Unor. Lantas apa yang dapat diharapkan untuk menangani urusan yang lebih besar? Dalam kondisi demikian, maka harapkanlah ketersediaan PTTI pada tiap-tiap Unor minimal satu orang, atau idealnya satu supervisi dan satu atau beberapa orang IT generalist atau IT specialist untuk DevOps.
Jika PTTI telah tersedia, maka apakah kerjanya harus langsung coding sepanjang waktu? Tidak demikian. Skill coding dan config itu sebuah kepastian yang cepat atau lambat harus dimiliki seorang PTTI. Namun fungsi yang lebih diperlukan atas eksistensi PTTI lebih kepada komunikasi dan sinergi untuk keperluan pemetaan fungsi-fungsi modular Unor ke dalam BPMN dan atau SPM berbasis SOTK. Dari sana akan lahir draft SOP untuk diuji penerapan sampai tidak lagi dirasa perlu adanya perubahan. Itu adalah arsitektur proses bisnis. Dari SOP tersebut dapat diperkirakan kisaran input dan output atas Probis. Dari input atau output itu biasanya akan mengacu kepada data yang memiliki meta data. Dari meta data tersebut didapatkan bahan untuk membuat rancangan database/ERD. Itu adalah Arsitektur Data.
Ilustri/siklus di atas cukup untuk menjadi bahan pembahasan inti artikel ini. IaaS sudah dapat dipastikan bukan pilihan untuk Unor yang tidak berkebutuhan khusus, sebab bicara IaaS maka bicara bagaimana menyelenggarakan pusat data. Bicara pusat data maka bicara masalah tuntutan Tier. Bicara tuntutan tier maka tidak ada pilihan tier di luar dari tier 1 hingga 4. Yang mana artinya pengorbanan dari sisi SDM, standar prosedur internasional, dan standar teknologi internasional. Maka pilihan yang tersisa hanya SaaS atau PaaS.
Software as a Services (SaaS) berarti entitas penyelenggara responsible tidak hanya proses layanan publik dan layanan administrasi, tapi juga pengembangan (development) dan operasional (operations) atas sistem elektronik (DevOps). Bukan hanya operator web, namun juga PTTI. SaaS ini tepat untuk siapa? Ini lebih tepat untuk entitas yang memerlukan aplikasi dengan fitur khusus untuk fungsi-fungsi modular atas tugas organisasi. Dengan satu orang PTTI dan layanan cloud hosting yang kredibel, semua proses penyelenggaraan sudah mulai bisa dijalankan. Ini tepat untuk Unor pada umumnya, dalam kondisi tidak ada aplikasi umum dari pemerintah pusat atau provinsi mengakomodir kebutuhan Unor tersebut. Dalam bahasa lain, tugas pertama PTTI itu bukan coding, bukan config, bukan BPMN atau ERD, tapi inventaris SOTK dan aplikasi umum yang mengakomodir Tusi Unor. Bilamana ada satu saja fungsi Unor yang tidak ada aplikasi umumnya, maka itu sudah lebih dari cukup menjadi alasan Unor untuk membuat proposal pembuatan/pengembangan aplikasi khusus untuk konsultasikan/didaftarkan ke Aptika pada daerahnya masing-masing, apakah aplikasi tersebut sebaiknya dilanjutkan atau dihentikan proses SDLC-nya. Tidak ada pilihan selain dari dua hal itu.
Platform as a Services (PaaS) berarti penyelenggaraan teknis layanan hanya berkutat kepada operator website. Ini sangat cocok untuk Probis-probis yang motifnya sama lagi berulang. Hanya perlu satu SK/ST, satu orang operator website, maka segalanya sudah dapat mulai dirintis. Tidak perlu satu SiLo untuk satu layanan, hanya perlu penambahan sub domain atau endpoint.
Kita ambil contoh penerapan SaaS/PaaS yakni SI Kecamatan/Desa dan Unor Perangkat Daerah. Untuk Unor Perangkat Daerah, kita ambil contoh JDIH.
SI Kecamatan/Desa dalam wujud SaaS, berarti setiap kecamatan/desa minimal ada satu PTTI, dan setiap PTTI mengambil daftar metadata yang sama untuk diintegrasikan ke pusatnya. Standarisasi metadata dapat mengacu kepada standarisasi dalam konteks keterpaduan layanan, maupun standar pelayanan tertentu. Lumrahnya kebijakannya berjumlah satu, dan polanya sama dan berulang di setiap kecamatan/desa.
SI Kecamatan/Desan dalam wujud PaaS, berarti setiap kecamatan/desa ada sekurang-kurangnya satu operator website. Sedangkan DevOps dapat ditangani internal pemerintah yang merupakan leading sector-nya, semisal kecamatan ditangani satu tingkat di atas kecamatan atau salah satu kecamatan, melalui PTTI dan wakilnya (jika ada pihak ketiga diperlukan). Begitu pula desa, maka sekurang-kurangnya ada satu operator website. Sedangkan DevOps dapat ditangani internal pemerintah yang merupakan leading sector-nya, semisal DPMD melalui PTTI dan wakilnya (jika ada pihak ketiga diperlukan). Adapun opsi Diskominfo untuk fungsi realisasi SaaS, ini tidak dapat berlangsung secara permanen, melainkan hanya sekadar pendampingan berjangka, sebab memang bukan Probis-nya (kecamatan/desa).
SI JDIH dalam wujud SaaS, dapat berwujud satu aplikasi monolith yang di-develop pemerintah pusat yang ditempatkan pada suatu repository dan dapat di-clone oleh kabupaten/kota/OPD yang telah memiliki SK atau ST PTTI. Siapa PTTI JDIH? Jawabannya adalah PTTI yang diambil dari Unor yang memiliki Probis berkenaan JDIH. PTTI tersebut akan berhadapan dengan task DevOps dan integrasi dengan API melalui SPL. Adapun Diskominfo untuk fungsi SaaS tidak dapat diberlakukan secara permanen, sebab JDIH bukan Probis-nya, kecuali untuk fungsi pendampingan teknis berjangka. Bagaimana jika tidak ada yang punya waktu cukup untuk menangani task PTTI full stack ataupun hanya sekadar supervisi? Opsi yang logis adalah belanja pegawai atau full PaaS.
SI JDIH dalam wujud PaaS, dapat berwujud satu aplikasi yang di-develop pemerintah pusat atau provinsi yang mana pada masing-masing bagian hukum pada kabupaten/kota hanya perlu dibuat SK atau ST operator web-nya. Aplikasi diakses melalui sub domain JDIH induk. Ini relevan untuk kondisi di mana dapat dipastikan pada JDIH pusat ada tata kelola dan up time yang baik dan layak untuk digeneralisir secara nasional.
Pada akhirnya strategi penentuan jenis layanan ini perlu di-tracing dari pemerintah pusat. Bilamana tidak ada layanan yang dapat digunakan, tidak ada rencana untuk pembuatan/pengembangan aplikasi yang diperlukan daerah, maka pembuatan aplikasi oleh daerah itu menjadi opsi atau keniscayaan. SaaS mensyaratkan PTTI, PaaS mensyaratkan Operator, IaaS sudah tidak relevan untuk daerah. Sedangkan apapun pilihannya mensyaratkan digital leadership yang cukup pada tiap-tiap jajaran manajerial, baik di dalam maupun di luar Diskominfo.