Rekayasa Perangkat Lunak dan Platform Sektor Publik

Mengapa ini penting dalam nilai publik

Hampir setiap layanan publik yang disentuh warga hari ini — mendaftarkan kelahiran, mengklaim tunjangan, membayar tagihan pajak, memesan jadwal pengadilan — berjalan di atas perangkat lunak di suatu tempat di balik konter atau layar. Perangkat lunak itu jarang berupa pembelian sekali jalan; ia menjadi bagian infrastruktur permanen negara, sering melampaui pemerintahan yang mengomisikannya, pemasok yang membangunnya, dan bahasa pemrograman yang dilatihkan kepada insinyurnya. Badan publik tidak mengalami perangkat lunak seperti ia mengalami gedung atau jalan, ketika kondisi aset terlihat; perangkat lunak merosot secara tak terlihat, dan tagihan atas pembusukan itu tiba bertahun-tahun kemudian sebagai keadaan darurat.

Ketegangan yang menggerakkan topik ini bersifat struktural. Perangkat lunak secara inheren iteratif — persyaratan menjadi lebih jelas seiring pengguna berinteraksi dengan sistem yang berfungsi, dan praktik rekayasa terbaik adalah membangun sesuatu yang kecil, belajar, dan beradaptasi. Siklus pengadaan dan akuntabilitas publik (lihat Topik 3.7 — Pengadaan Publik dan Komisioning), sebaliknya, dibangun untuk pekerjaan modal dan kontrak pertahanan: spesifikasi tetap, satu penghargaan besar, pembayaran per tonggak, dan kajian bisnis yang disahkan bertahun-tahun sebelum penyampaian dimulai. Ketika legislatif atau auditor mengharapkan kontrak harga-tetap dan lingkup-tetap dan tim rekayasa perlu mengubah arah setelah rilis pertama, ketidakcocokan itu tampak sebagai perayapan lingkup, pembengkakan anggaran, atau sistem yang dispesifikasi dengan benar pada 2019 dan usang pada saat ia dikirim.

Platform yang ada praktik rekayasa topik ini untuk membangunnya — sistem identitas bersama, jalur pembayaran, perangkat manajemen kasus yang dipakai ulang lintas departemen — adalah pokok bahasan Topik 5.1 (lihat Topik 5.1 — Pemerintahan Digital dan Transformasi Digital); topik ini membahas disiplin membangun dan membeli perangkat lunak yang membuat platform semacam itu, atau satu layanan mana pun, andal, dapat diganti, dan dimiliki oleh badan publik yang bergantung padanya alih-alih oleh pemasok mana pun yang kebetulan menulisnya lebih dulu.

Konsep inti

Keputusan bangun-versus-beli adalah pilihan antara mengomisikan perangkat lunak pesanan yang ditulis untuk kebutuhan satu organisasi dan mengadopsi perangkat lunak komoditas yang dapat dikonfigurasi yang sudah dibangun untuk pasar pembeli serupa. Membeli biasanya lebih murah dan berisiko lebih rendah untuk kebutuhan yang tidak sungguh khas — penggajian, surel, manajemen kasus baku — sementara membangun dibenarkan hanya di mana persyaratan cukup berbeda sehingga tidak ada produk yang dapat dikonfigurasi yang cocok, atau di mana kapabilitas itu sendiri aset strategis yang perlu dimiliki dan dikembangkan organisasi.

Utang teknis adalah metafora, diciptakan insinyur perangkat lunak Ward Cunningham pada 1992, untuk biaya terakumulasi dari memilih cara praktis mengirim perangkat lunak sekarang daripada cara lebih menyeluruh yang akan memakan waktu lebih lama. Utang teknis, seperti utang finansial, tidak inheren salah untuk diambil — maksud Cunningham sendiri adalah bahwa mengirim kode yang berfungsi dengan cepat dan merefaktor sesudahnya dapat menjadi keputusan yang tepat — tetapi utang yang tak pernah dibayar mengumpulkan bunga sebagai penyampaian lebih lambat, lebih banyak cacat, dan risiko yang meningkat, dan badan publik yang tidak dapat melihat utangnya tidak dapat memutuskan apakah akan melunasinya atau membiarkannya menumpuk.

Sistem warisan adalah teknologi, aplikasi, atau platform lama yang tetap dipakai aktif meski usang, sering karena menggantinya mahal atau karena tak seorang pun yang tersisa dalam organisasi sepenuhnya memahami apa yang dilakukannya. Sistem warisan sangat menetap di pemerintahan: sistem pajak, tunjangan, dan asuransi sosial inti yang ditulis berdekade lalu dalam bahasa seperti COBOL — Common Business-Oriented Language, dirancang 1960 untuk komputasi administratif — masih memproses transaksi bagi jutaan warga, karena sistem itu berfungsi dan pengetahuan kelembagaan yang dibutuhkan untuk mempensiunkannya dengan aman sering sudah pensiun lebih dulu.

Modernisasi perangkat lunak adalah istilah umum untuk mengonversi, menulis ulang, atau memigrasikan sistem warisan ke arsitektur, bahasa, atau platform terkini. Modernisasi perangkat lunak membentang dari penulisan ulang penuh hingga opsi lebih konservatif seperti menempatkan ulang kode yang sama pada infrastruktur modern, dan pilihan di antaranya sama banyaknya keputusan manajemen risiko seperti teknis.

Pola pencekik ara adalah pendekatan modernisasi inkremental, dinamai menurut tanaman merambat yang tumbuh mengelilingi pohon inang dan lambat laun menggantikannya, di mana fungsionalitas baru dibangun berdampingan dengan sistem warisan dan lalu lintas dialihkan ke sana sepotong demi sepotong, alih-alih mengganti seluruh sistem dalam satu peralihan. Pola pencekik ara penting karena memungkinkan setiap tambahan diuji, dibalik, atau dijeda tanpa menurunkan seluruh layanan — kebalikan dari penggantian ledakan-besar, ketika sistem lama dimatikan dan yang baru dinyalakan dalam satu saat tanpa jalan kembali jika ada yang salah.

Keterkuncian vendor terjadi ketika pelanggan menjadi begitu bergantung pada teknologi proprietari, format data, atau syarat kontrak satu pemasok sehingga beralih ke pemasok lain membawa biaya atau risiko yang prohibitif. Keterkuncian vendor adalah bahaya khusus dalam perangkat lunak sektor publik karena pembeli adalah pelanggan berulang dengan kemampuan praktis terbatas untuk meninggalkan sistem yang menjalankan layanan kritis, yang melemahkan posisi tawarnya pada setiap pembaruan berikutnya.

Perangkat lunak bebas dan sumber terbuka adalah perangkat lunak yang didistribusikan di bawah lisensi yang memberi pengguna kebebasan memakai, mempelajari, memodifikasi, dan mendistribusikan ulang kode sumber. Perangkat lunak bebas dan sumber terbuka mendasari kebijakan sumber-terbuka-secara-bawaan, di bawahnya badan publik secara bawaan mempublikasikan kode sumber yang dikomisikannya kecuali alasan spesifik — kepekaan keamanan, hak pihak ketiga — membenarkan penahanannya; dasar pemikirannya biasanya diringkas sebagai "uang publik, kode publik": perangkat lunak yang dibayar sekali dengan dana publik tidak seharusnya perlu dibayar lagi, di yurisdiksi berbeda, oleh badan publik berbeda yang memecahkan masalah yang sama.

Barang publik digital adalah perangkat lunak, data, atau konten terbuka, dirilis di bawah lisensi terbuka, dirancang membantu memenuhi tujuan pembangunan atau tata kelola publik alih-alih menghasilkan imbal hasil komersial. Barang publik digital membingkai ulang rilis sumber terbuka satu pemerintah sebagai bagian infrastruktur bersama yang lebih luas yang dapat dimanfaatkan langsung pemerintah lain dan organisasi masyarakat sipil, bukan hanya isyarat transparansi internal.

Pengembangan perangkat lunak tangkas adalah istilah payung untuk pendekatan iteratif membangun perangkat lunak yang mengutamakan perangkat lunak yang berfungsi, penyampaian sering, dan menanggapi perubahan daripada mengikuti rencana tetap yang disepakati sebelumnya. Pengembangan perangkat lunak tangkas berbeda dari model air terjun, pendekatan berurutan ketika persyaratan, perancangan, pembangunan, dan pengujian masing-masing selesai penuh sebelum yang berikutnya dimulai; daya tarik air terjun bagi badan publik selalu bahwa tonggaknya terpetakan rapi pada kontrak harga-tetap dan siklus anggaran tahunan, itulah mengapa begitu banyak hukum pengadaan masih mengasumsikannya, bahkan di mana penyampaian sungguh tangkas.

Produk minimum yang layak adalah versi terkecil dari layanan yang dapat dirilis kepada pengguna nyata untuk menguji apakah ia berhasil dan mempelajari apa yang dibangun berikutnya. Konsep produk minimum yang layak, diadaptasi ke dalam buku panduan layanan digital sektor publik, memberi tim iteratif cara yang dapat dipertahankan untuk menunjukkan kepada penyandang dana atau auditor sesuatu yang nyata dan berfungsi jauh sebelum lingkup penuh selesai — asalkan proses akuntabilitas menerima rilis yang sungguh minimal alih-alih memperlakukannya sebagai produk jadi di bawah nama berbeda.

Praktik terbaik

1. Bawaan membeli untuk kebutuhan yang tak terdiferensiasi, dan sediakan membangun untuk apa yang sungguh khas. Penggajian, surel, dan kebutuhan manajemen kasus umum jarang cukup berbeda dari organisasi lain mana pun untuk membenarkan perangkat lunak pesanan; bangun hanya di mana persyaratan, skala, atau kebutuhan memiliki dan mengembangkan kapabilitas selama beberapa dekade sungguh berbeda dari yang ditawarkan pasar.
2. Buat utang teknis terlihat sebelum memutuskan berapa banyak yang dipikul. Pelihara register jalan pintas yang diketahui, perbaikan yang ditunda, dan ketergantungan tak terdukung untuk setiap sistem yang beroperasi, ditinjau pada siklus tetap, agar memikul utang satu tahun lagi adalah pertukaran yang disengaja dan bukan karena tak seorang pun melihat.
3. Jangan pernah merencanakan satu peralihan tak dapat dibalik sebagai satu-satunya jalan keluar dari sistem warisan kritis. Pilih pendekatan inkremental seperti pola pencekik ara yang memungkinkan tiap bagian diuji, dibalik, dan diluncurkan bertahap; penggantian ledakan-besar sistem yang menjadi sandaran jutaan orang memusatkan risiko bertahun-tahun ke dalam satu akhir pekan tanpa jalan kembali jika ada yang gagal.
4. Perlakukan kode sumber yang dibayar organisasi Anda untuk ditulis sebagai aset yang dimilikinya, bukan layanan yang disewanya. Rundingkan escrow kode sumber atau kepemilikan penuh pada saat berkontrak, bukan setelah sengketa dimulai, sebab pemasok yang memegang satu-satunya salinan kode layanan kritis Anda adalah keterkuncian vendor sejak rancangan.
5. Publikasikan kode sumber sebagai terbuka secara bawaan, dan wajibkan pembenaran spesifik untuk menahannya. Kebijakan sumber-terbuka-secara-bawaan, diterapkan konsisten, mengubah perangkat lunak buatan khusus setiap departemen menjadi aset bersama lintas pemerintah alih-alih biaya sekali jalan, dan memungkinkan pakar luar menemukan cacat keamanan yang akan terlewat oleh tim internal sendirian.
6. Tulis kontrak perangkat lunak yang menjadikan penyampaian iteratif sah secara hukum, bukan hanya mungkin secara teknis. Kontrak yang hanya membayar terhadap spesifikasi tetap yang disepakati saat penandatanganan memaksa tim memilih antara praktik tangkas yang jujur dan kepatuhan kontrak; pakai gerbang pendanaan bertahap yang terkait dengan perangkat lunak berfungsi yang didemonstrasikan sebagai gantinya satu tonggak di akhir.
7. Danai modernisasi sebagai program berkelanjutan, bukan proyek modal sekali jalan. Sistem warisan yang dimodernisasi sekali lalu dibiarkan dua puluh tahun lagi mengumpulkan risiko yang sama seperti ketika dimulai; anggarkan pembaruan inkremental berkelanjutan sebagaimana otoritas jalan menganggarkan pelapisan ulang, bukan penggantian besar sekali satu generasi.
8. Pilih standar terbuka dan format data yang dapat dipindahkan bahkan ketika membeli perangkat lunak komersial. Mewajibkan sistem pemasok menyimpan dan mengekspor data dalam format terbuka yang terdokumentasi menjaga biaya beralih tetap rendah bahkan di mana perangkat lunaknya sendiri proprietari, dan sering pengaman jangka dekat yang lebih dapat dicapai terhadap keterkuncian daripada bersikeras bahwa setiap sistem harus sumber terbuka.
9. Bangun produk minimum yang layak dan tunjukkan kepada pengguna nyata sebelum berkomitmen pada lingkup penuh. Merilis versi yang sungguh minimal, lalu beriterasi atas apa yang dipelajari, menangkap asumsi keliru selagi masih murah diperbaiki, alih-alih setelah sistem skala penuh dibangun terhadapnya.
10. Pertahankan kapabilitas rekayasa internal yang memadai untuk menjadi pembeli cerdas, bahkan di mana penyampaian dialihdayakan. Badan publik yang telah mengosongkan keahlian teknisnya tidak dapat menilai proposal pemasok, mengenali tanda peringatan dini proyek bermasalah, atau berunding keluar dari keterkuncian, apa pun yang dikatakan aturan pengadaannya di atas kertas.
11. Pensiunkan profil risiko sistem warisan sebelum antarmuka penggunanya. Prioritaskan mengganti bahasa tak terdukung, infrastruktur tak ditambal, dan integrasi tak terdokumentasi — kegagalan yang menyebabkan pemadaman dan pelanggaran — mendahului modernisasi visual yang membawa risiko operasional jauh lebih kecil.
12. Ukur kesehatan penyampaian dengan indikator rekayasa, bukan hanya selisih anggaran dan jadwal. Frekuensi penerapan, tingkat cacat, dan usia butir utang teknis tertua yang belum ditangani memberi tahu dewan tata kelola lebih banyak tentang apakah program akan berhasil daripada apakah ia saat ini sesuai anggaran, sering indikator terakhir yang bergerak.

Pertanyaan untuk didiskusikan dengan tim Anda

Apakah kita benar-benar tahu berapa banyak utang teknis yang kita pikul, sistem demi sistem? Sebagian besar badan publik dapat menyatakan anggaran modal tahunannya tetapi tidak dapat menyatakan, dengan keyakinan apa pun, berapa banyak estat perangkat lunaknya berjalan pada komponen tak terdukung, logika tak terdokumentasi, atau kode yang tidak sepenuhnya dipahami siapa pun yang tersisa di staf. Gunakan pertanyaan ini untuk meminta setiap pemilik sistem di ruangan memperkirakan, dengan jujur, seberapa yakin mereka bahwa tim mereka dapat dengan aman mengubah sistem paling kritisnya tanpa merusak sesuatu yang tidak diantisipasi siapa pun. Diskusikan apa yang diperlukan untuk mengubah perkiraan itu menjadi register sungguhan, ditinjau pada siklus tetap, alih-alih pengetahuan lisan yang pergi ketika insinyur kunci pergi. Pertimbangkan juga siapa yang saat ini memutuskan seberapa banyak utang yang dapat diterima untuk dipikul, dan apakah keputusan itu disengaja atau bawaan.

Jika sistem warisan paling kritis kita perlu diganti mulai hari ini, akankah kita merencanakan peralihan ledakan-besar atau migrasi inkremental — dan mengapa? Naluri mengganti sistem lama sekaligus sering digerakkan oleh siklus anggaran dan kenyamanan manajemen program alih-alih keharusan teknis, dan memusatkan risiko besar ke dalam satu saat. Gunakan pertanyaan ini untuk menelusuri, secara konkret, seperti apa migrasi inkremental bergaya pencekik ara dari sistem warisan paling kritis Anda, sepotong demi sepotong. Diskusikan apa yang menghalangi Anda memilih jalur itu hari ini — pendanaan yang disusun di sekitar satu tanggal peluncuran, proses tata kelola yang menginginkan satu tonggak bersih, atau kendala teknis sejati yang membuat migrasi inkremental mustahil untuk sistem ini.

Siapa yang sebenarnya memiliki kode sumber untuk perangkat lunak yang telah dibayar organisasi kita untuk dibangun, dan dapatkah kita membuktikannya? Banyak badan publik menemukan, hanya ketika hubungan dengan pemasok memburuk, bahwa kontrak tidak pernah mengamankan kepemilikan atau escrow yang jelas atas kode yang menjadi sandaran layanan kritis mereka. Gunakan pertanyaan ini untuk menarik kontrak tiga sistem pesanan terpenting Anda dan periksa, secara spesifik, apa yang dikatakan masing-masing tentang kepemilikan kode, escrow, dan hak membawa kode ke pemasok lain. Diskusikan apa yang akan terjadi besok jika pemasok utama Anda untuk salah satu dari ketiga sistem itu bangkrut atau menolak melanjutkan hubungan.

Di mana kita memilih perangkat lunak proprietari tertutup karena kebiasaan, padahal pendekatan sumber-terbuka-secara-bawaan akan melayani kita sama baik atau lebih baik? Kebijakan sumber-terbuka-secara-bawaan ada justru karena sebagian besar badan publik memecahkan masalah yang tumpang tindih secara independen, masing-masing membayar penuh biaya perangkat lunak yang sudah dibangun badan publik lain dan dapat dibagikan. Gunakan pertanyaan ini untuk mengidentifikasi satu sistem yang saat ini sedang dibangun atau dispesifikasi dan tanyakan apakah padanan sudah ada sebagai perangkat lunak sumber terbuka di tempat lain dalam pemerintahan, atau apakah yang sedang Anda bangun dapat dirilis berguna untuk dipakai ulang orang lain. Diskusikan hambatan spesifik apa — kekhawatiran keamanan, kebiasaan pengadaan, ketiadaan kebijakan yang jelas — yang sebenarnya menghalangi pemakaian ulang itu, alih-alih mengasumsikan itu tidak relevan di sini.

Apakah proses pengadaan dan akuntabilitas kita benar-benar mengizinkan penyampaian tangkas yang jujur, atau hanya menamai ulang tonggak air terjun sebagai sprint? Lazim tim menjalankan upacara nominal tangkas sambil tetap didanai, ditata kelola, dan dilaporkan terhadap spesifikasi tetap yang disepakati saat penandatanganan kontrak, yang menciptakan kembali setiap ragam kegagalan air terjun di bawah label tangkas. Gunakan pertanyaan ini untuk menelusuri satu program digital hidup dari kajian bisnisnya melalui pelaporan tata kelola saat ini dan tanyakan apakah struktur pendanaan akan mentoleransi program berubah arah berdasarkan apa yang diajarkan rilis awal sejati padanya. Diskusikan apa yang perlu berubah dalam cara program didanai dan dilaporkan agar penyampaian iteratif nyata dan bukan kosmetik (lihat Topik 3.7 — Pengadaan Publik dan Komisioning).

Apakah kita memiliki kapabilitas rekayasa internal yang cukup untuk menjadi pembeli cerdas atas sistem yang paling kita andalkan? Organisasi yang telah mengalihdayakan seluruh pertimbangan teknisnya, bukan hanya kapasitas penyampaiannya, tidak dapat mengetahui apakah proposal pemasok sehat, apakah proyek diam-diam menuju masalah, atau berapa harga wajar pekerjaan itu. Gunakan pertanyaan ini untuk menanyakan berapa banyak orang di organisasi Anda yang secara kredibel dapat meninjau proposal arsitektur teknis untuk sistem terpenting Anda, dan bagaimana angka itu berubah selama lima tahun terakhir. Diskusikan apa yang diperlukan untuk membangun kembali kapabilitas itu di mana ia telah terkikis, dan apa yang hilang dari organisasi Anda, dalam posisi tawar sama seperti risiko penyampaian, untuk setiap tahun tanpanya.

Dalam praktik: contoh nilai publik

Pemerintah regional fiktif — ilustratif semata, bukan gambaran yurisdiksi sungguhan mana pun — menjalankan klaim tunjangan penganggurannya melalui sistem yang pertama kali ditulis lebih dari tiga puluh tahun sebelumnya, dipelihara oleh jumlah insinyur yang menyusut yang memahami bahasa pemrograman aslinya. Volume klaim telah tumbuh jauh melampaui yang diantisipasi perancang sistem, proses pemrosesan malam hari makin sering gagal selesai sebelum transaksi pagi dimulai, dan pimpinan teknologi badan memperingatkan bahwa pemadaman tak terencana yang memengaruhi pembayaran tunjangan kini soal kapan, bukan apakah.

Naluri pertama badan adalah tanggapan konvensional atas masalah yang terasa mendesak: mengomisikan satu kontrak besar untuk mengganti seluruh sistem dengan platform modern, dispesifikasi penuh di muka, disampaikan terhadap garis waktu dua tahun tetap dengan satu akhir pekan peralihan di ujung. Tinjauan pra-pelaksanaan yang ditugaskan komite audit badan mengajukan pertanyaan keras sebelum kontrak ditandatangani: apa yang akan terjadi pada pembayaran tunjangan bagi beberapa ratus ribu pemohon jika sistem baru memiliki cacat yang belum ditemukan pada minggu pertama operasi hidup skala penuh, dengan sistem lama sudah dinonaktifkan dan tidak ada jalan kembali.

Badan mengubah arah. Ia mempertahankan sistem warisan berjalan sebagai sistem pencatatan dan mulai membangun fungsionalitas penerimaan klaim dan penilaian kelayakan baru di sampingnya, memakai pendekatan pencekik ara: setiap modul baru dirilis lebih dulu ke persentase kecil klaim baru, diverifikasi terhadap keluaran paralel sistem lama, dan diperluas hanya setelah hasilnya cocok. Dalam delapan belas bulan, sebagian besar klaim baru berjalan melalui komponen modern sementara sistem asli menangani beban kasus sisa yang menyusut, dengan kemampuan mengalihkan kasus tunggal mana pun kembali ke jalur lama jika ada yang tampak salah. Badan juga mewajibkan, dalam setiap kontrak baru yang diterbitkan untuk pekerjaan ini, bahwa kode sumber dimiliki badan dan dipublikasikan sebagai sumber terbuka setelah tinjauan keamanan selesai, agar pemerintah regional lain yang menghadapi masalah mainframe menua yang sama dapat mengadaptasi komponen alih-alih mengulang pembangunan yang sama dari nol.

Penggantian penuh fungsi sisa terakhir sistem warisan memakan waktu hampir empat tahun — lebih lama, di atas kertas, daripada yang dijanjikan rencana ledakan-besar dua tahun semula. Tetapi tidak ada pemohon yang pernah mengalami pemadaman tak terencana selama transisi, setiap tambahan cukup kecil untuk dibalik dalam hitungan jam ketika cacat ditemukan, dan dua pemerintah regional bertetangga mulai mengadaptasi kode penilaian kelayakan badan yang dipublikasikan untuk sistem mereka sendiri dalam tahun pertama rilisnya.

Empat lensa sektoral

Pemerintah daerah

Pemerintah daerah biasanya menjalankan banyak sistem yang lebih kecil dan terputus alih-alih segelintir platform skala nasional, yang berarti utang teknis menumpuk lintas banyak aplikasi yang diadakan dan dipelihara terpisah alih-alih dalam satu sistem unggulan yang terlihat. Otoritas daerah biasanya memiliki kapabilitas rekayasa internal paling sedikit di antara tingkat pemerintahan mana pun, membuat argumen untuk membeli perangkat lunak komoditas yang dapat dikonfigurasi daripada pembangunan pesanan sangat kuat, dan menjadikan platform bersama regional atau nasional — pokok bahasan Topik 5.1 (lihat Topik 5.1 — Pemerintahan Digital dan Transformasi Digital) — jalur bernilai sangat tinggi untuk menghindari masing-masing otoritas membangun ulang kapabilitas yang sama secara terpisah.

Pemerintah nasional

Pemerintah nasional adalah tempat sistem warisan tertua dan paling konsekuensial cenderung berada — administrasi pajak inti, asuransi sosial, dan tunjangan — karena ini sering termasuk upaya komputerisasi skala besar pertama di pemerintahan dan kini membawa taruhan tertinggi bagi kegagalan modernisasi apa pun. Pemerintah nasional biasanya memiliki kapabilitas komersial dan rekayasa spesialis untuk menjalankan program modernisasi yang sungguh inkremental dan merundingkan kepemilikan kode nyata ke dalam kontraknya, dan biasanya tingkat pemerintahan yang paling baik berada untuk menetapkan kebijakan sumber-terbuka-secara-bawaan dengan skala cukup di belakangnya untuk membuat pemakaian ulang lintas pemerintah benar-benar terjadi.

Sektor sosial dan nirlaba

Organisasi nirlaba dan lembaga amal jarang membangun platform pesanan besar sendiri, tetapi sering berada di sisi penerima perangkat lunak yang dikomisikan atau diwajibkan penyandang dana pemerintah — portal pelaporan, sistem manajemen kasus yang diharuskan hibah atau kontrak untuk mereka pakai — dengan sedikit pengaruh atas perancangan, utang teknis, atau vendornya. Organisasi sektor sosial yang bergantung pada sistem yang diwajibkan pemerintah mewarisi ragam kegagalan sistem itu tanpa mewarisi pengungkit apa pun untuk memperbaikinya, satu lagi alasan hubungan pendanaan berbasis hasil perlu memperhitungkan beban operasional teknologi yang diwajibkan (lihat Topik 3.7 — Pengadaan Publik dan Komisioning), bukan hanya metrik hasil itu sendiri.

Multilateral dan internasional

Badan multilateral dan badan pembangunan semakin mempromosikan perangkat lunak yang dibangun untuk administrasi publik satu negara sebagai barang publik digital yang dapat diadaptasi negara lain, alih-alih setiap pemerintah mengomisikan sistem setara dari pemasok swasta dengan biaya penuh. Risiko khas di sini adalah bahwa barang publik digital yang dibangun untuk konteks hukum dan administratif satu negara dapat diadopsi di tempat lain dengan terlalu sedikit adaptasi, mengimpor asumsi — tentang identitas, kelayakan, atau proses — yang sebenarnya tidak berpindah; janji infrastruktur bersama yang terbuka itu nyata, tetapi hanya di mana kapasitas adaptasi lokal sejati menyertai kodenya.

Ragam kegagalan yang umum

Peralihan ledakan-besar yang gagal saat peluncuran. Sistem warisan kritis diganti dalam satu peralihan tak dapat dibalik setelah bertahun-tahun pengembangan tanpa paparan produksi hidup, dan cacat yang hanya muncul pada skala nyata atau dalam kasus tepi yang tidak diuji siapa pun muncul pada hari pertama operasi penuh, tanpa cara kembali ke sistem lama karena sudah dinonaktifkan. Biayanya diukur dalam pembayaran yang terlewat, layanan yang ditolak, atau pemadaman yang memengaruhi persis warga yang dilayani sistem, pada saat terburuk — saat semua orang bergantung pada penggantinya berfungsi.

Akumulasi utang teknis yang senyap. Tekanan tenggat berulang kali memenangkan argumen melawan waktu yang dibutuhkan untuk memperbaiki jalan pintas yang diketahui, dan setiap penundaan dapat dipertahankan secara individual, sampai utang yang menumpuk membuat bahkan perubahan kecil tidak proporsional mahal dan berisiko. Biayanya muncul bertahun-tahun kemudian sebagai sistem yang tak seorang pun dapat dengan aman memodifikasinya, tenaga kerja yang diam-diam berhenti mencoba apa pun kecuali tambalan paling mendesak, dan program modernisasi akhirnya jauh lebih besar dan lebih mahal daripada pembaruan berkelanjutan yang lebih kecil.

Keterkuncian vendor disangka stabilitas. Badan publik memperbarui kontrak pemasok yang sama berulang kali karena beralih tampak terlalu mengganggu untuk dicoba, tanpa pernah menguji berapa biaya beralih yang sebenarnya atau merundingkan kepemilikan kode dan format data terbuka yang akan menjaga biaya itu tetap terkelola. Biayanya adalah posisi tawar yang melemah secara permanen pada harga dan syarat, baru ditemukan ketika mutu layanan pemasok menurun atau harganya naik dan badan publik mendapati tidak punya alternatif yang kredibel.

Tangkas kosmetik. Tim penyampaian mengadopsi upacara tangkas — rapat berdiri, sprint, tumpukan tugas — sementara struktur kontrak, pendanaan, dan tata kelola yang mendasarinya masih mengasumsikan spesifikasi tetap dan satu tonggak lanjut/hentikan, sehingga tim melaporkan kecepatan sprint sambil sebenarnya menyampaikan terhadap rencana air terjun di bawahnya. Biayanya adalah bahwa tak satu pun keuntungan sejati tangkas — umpan balik pengguna dini yang mengubah arah, risiko yang muncul lebih awal — terwujud, sementara kesan praktik modern membuat kekakuan yang mendasarinya lebih sulit dilihat dan ditantang badan pengawas.

Kebijakan sumber terbuka tanpa rencana penopang. Badan publik mempublikasikan kode sumber untuk memenuhi kebijakan sumber-terbuka-secara-bawaan tetapi memperlakukan rilis sebagai langkah kepatuhan sekali jalan, tanpa pembiayaan untuk meninjau kontribusi eksternal, menambal kerentanan, atau memelihara dokumentasi. Biayanya adalah repositori terpublikasi yang tampak terbuka tetapi berfungsi sebagai jalan buntu tak terpelihara, yang merusak kepercayaan pada program sumber-terbuka-secara-bawaan yang lebih luas lebih daripada tidak pernah mempublikasikan sama sekali.

Model kematangan

Daftar periksa

• Inventarisasi utang teknis setiap sistem kritis dan tinjau register pada siklus tetap.
• Terapkan kerangka bangun-versus-beli terdokumentasi sebelum berkomitmen pada perangkat lunak baru yang signifikan.
• Untuk penggantian sistem warisan apa pun, jadikan metode migrasi inkremental bawaan dan wajibkan pembenaran eksplisit untuk peralihan ledakan-besar.
• Pastikan syarat kepemilikan atau escrow kode sumber dalam setiap kontrak perangkat lunak sebelum penandatanganan.
• Publikasikan kode sumber di bawah kebijakan sumber-terbuka-secara-bawaan, dengan proses pengecualian terdokumentasi.
• Biayai pemeliharaan berkelanjutan untuk setiap repositori yang dipublikasikan di bawah kebijakan itu, tidak hanya rilis awalnya.
• Wajibkan format data terbuka yang terdokumentasi bahkan di mana perangkat lunak yang mendasarinya proprietari.
• Susun gerbang pendanaan di sekitar perangkat lunak berfungsi yang didemonstrasikan alih-alih satu tonggak spesifikasi tetap.
• Bangun dan uji produk minimum yang layak dengan pengguna nyata sebelum berkomitmen pada lingkup penuh.
• Lacak frekuensi penerapan, tingkat cacat, dan utang teknis yang belum diselesaikan sebagai indikator tata kelola tetap.
• Nilai kapabilitas rekayasa internal terhadap apa yang dibutuhkan untuk menjadi pembeli cerdas, dan tutup celah yang teridentifikasi.
• Prioritaskan infrastruktur tak terdukung dan integrasi tak terdokumentasi mendahului modernisasi kosmetik.

Sumber utama

• GOV.UK Service Standard, Government Digital Service, Britania Raya — standar layanan digital nasional yang mewajibkan penyampaian iteratif berpusat pada pengguna dan standar terbuka untuk layanan publik.
• Office of Management and Budget, Federal Source Code Policy (M-16-21), Amerika Serikat — kebijakan federal yang mewajibkan lembaga mempertimbangkan pemakaian ulang dan rilis sumber terbuka untuk perangkat lunak pemerintah yang dikembangkan khusus.
• Free Software Foundation Europe, kampanye Public Money, Public Code — dasar pemikiran, dikembangkan untuk khalayak Eropa, untuk merilis kode sumber perangkat lunak yang didanai publik di bawah lisensi bebas dan sumber terbuka.
• Ward Cunningham, "The WyCash Portfolio Management System" (laporan pengalaman OOPSLA 1992) — pernyataan asli metafora utang teknis.
• Digital Public Goods Alliance — inisiatif multipemangku kepentingan yang memelihara standar dan registri untuk perangkat lunak, data, dan konten terbuka yang dirancang melayani tujuan pembangunan publik.

Referensi

1. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
2. Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
3. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
4. COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
5. Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
6. Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
9. Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
11. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
12. Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
13. Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
14. Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
15. Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
16. "The WyCash Portfolio Management System" (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
17. Digital Public Goods Alliance — https://digitalpublicgoods.net/