Konu 5.3 — Kamu Sektörü Yazılım Mühendisliği ve Platformlar

Bu neden kamu değeri açısından önemlidir

Bir yurttaşın bugün dokunduğu hemen her kamu hizmeti — bir doğumu kaydetmek, bir yardım talep etmek, bir vergi faturasını ödemek, bir mahkeme tarihi almak — tezgâhın ya da ekranın ardında bir yerde yazılım üzerinde çalışır. O yazılım nadiren tek seferlik bir satın almadır; devletin kalıcı altyapısının bir parçası olur, çoğu zaman onu görevlendiren yönetimden, onu inşa eden tedarikçiden ve mühendislerinin eğitildiği programlama dilinden daha uzun yaşar. Bir kamu kuruluşu yazılımı, varlığın durumunun görünür olduğu bir bina ya da yol gibi deneyimlemez; yazılım görünmez biçimde bozulur ve çürümenin faturası yıllar sonra bir acil durum olarak gelir.

Bu konuyu yönlendiren gerilim yapısaldır. Yazılım doğası gereği yinelemelidir — gereksinimler kullanıcılar çalışan bir sistemle etkileşime girdikçe netleşir ve en iyi mühendislik pratiği küçük bir şey inşa etmek, öğrenmek ve uyum sağlamaktır. Kamu alımları ve hesap verebilirlik döngüleri (bkz. Konu 3.7 — Kamu Alımları ve Hizmet Tedariki) ise tersine sermaye işleri ve savunma sözleşmeleri için kurulmuştur: sabit bir belirtim, tek büyük bir ihale, aşamalı ödemeler ve teslim başlamadan yıllar önce onaylanmış bir iş gerekçesi. Bir yasama organı ya da bir denetçi sabit fiyatlı, sabit kapsamlı bir sözleşme beklediğinde ve bir mühendislik ekibinin ilk sürümden sonra rotasını değiştirmesi gerektiğinde, uyumsuzluk kapsam sürünmesi, bütçe aşımı ya da 2019'da doğru belirtilmiş ve gönderildiği zamana kadar eskimiş bir sistem olarak görünür.

Bu konunun mühendislik pratiğinin inşa etmek için var olduğu platformlar — paylaşılan kimlik sistemleri, ödeme hatları, bakanlıklar arasında yeniden kullanılan vaka yönetimi araçları — Konu 5.1'in konusudur (bkz. Konu 5.1 — Dijital Devlet ve Dijital Dönüşüm); bu konu, herhangi bir böyle platformu ya da herhangi bir tek hizmeti güvenilir, değiştirilebilir ve ilk yazan tedarikçi değil ona bağımlı kamu kuruluşu tarafından sahip olunan kılan yazılımı inşa etme ve satın alma disiplinidir.

Temel kavramlar

İnşa et–satın al kararı, tek bir kuruluşun ihtiyacı için yazılmış ısmarlama yazılımı görevlendirmek ile benzer alıcılardan oluşan bir piyasa için zaten kurulmuş yapılandırılabilir meta yazılımı benimsemek arasındaki seçimdir. Satın almak, gerçekten ayırt edici olmayan bir ihtiyaç — bordro, e-posta, standart vaka yönetimi — için genellikle daha ucuz ve daha düşük risklidir; inşa etmek ise yalnızca gereksinim hiçbir yapılandırılabilir ürünün uymayacağı kadar farklı olduğunda ya da yeteneğin kendisi kuruluşun sahip olması ve geliştirmesi gereken stratejik bir varlık olduğunda haklıdır.

Teknik borç, yazılım mühendisi Ward Cunningham tarafından 1992'de ortaya atılan bir metafordur; yazılımı şimdi göndermek için daha uzun sürecek daha kapsamlı bir yol yerine elverişli bir yolu seçmenin birikmiş maliyetini anlatır. Teknik borç, mali borç gibi, üstlenilmesi doğası gereği yanlış değildir — Cunningham'ın kendi noktası, çalışan kodu hızla göndermenin ve sonra yeniden düzenlemenin doğru çağrı olabileceğiydi — ama hiç ödenmeyen borç daha yavaş teslim, daha fazla kusur ve artan risk olarak faiz biriktirir ve borcunu göremeyen bir kamu kuruluşu onu ödemeye mi yoksa bileşik hâle gelmesine mi izin vereceğine karar veremez.

Eski sistem, eskimiş olmasına rağmen etkin kullanımda kalan eski bir teknoloji, uygulama ya da platformdur; çoğu zaman değiştirmek pahalı olduğu için ya da kuruluşta kalan hiç kimse ne yaptığını tam olarak anlamadığı için. Eski sistemler hükümette özellikle kalıcıdır: onlarca yıl önce COBOL — 1960'ta idari bilişim için tasarlanmış Common Business-Oriented Language — gibi dillerde yazılmış çekirdek vergi, yardım ve sosyal sigorta sistemleri hâlâ milyonlarca yurttaş için işlem yapar; çünkü sistemler çalışır ve onları güvenle emekliye ayırmak için gereken kurumsal bilgi çoğu zaman önce kendisi emekli olmuştur.

Yazılım modernizasyonu, bir eski sistemi güncel bir mimariye, dile ya da platforma dönüştürme, yeniden yazma ya da taşımanın genel adıdır. Yazılım modernizasyonu, tam bir yeniden yazımdan aynı kodu modern altyapıda yeniden barındırmak gibi daha muhafazakâr seçeneklere kadar bir yelpazeyi kapsar ve aralarındaki seçim teknik olduğu kadar bir risk yönetimi kararıdır.

Boğucu incir örüntüsü, bir konağı ağacın etrafında büyüyen ve onu kademeli olarak değiştiren bir asmanın adını taşıyan, yeni işlevselliğin bir eski sistemin yanında inşa edildiği ve trafiğin tüm sistemi tek bir geçişle değiştirmek yerine parça parça ona yönlendirildiği, artımlı bir modernizasyon yaklaşımıdır. Boğucu incir örüntüsü önemlidir, çünkü her artışın tüm hizmeti aşağı çekmeden sınanmasına, geri alınmasına ya da duraklatılmasına izin verir — eski sistemin kapatılıp yenisinin tek bir anda açıldığı, bir şey yanlışsa geri dönüş yolu olmayan büyük patlamalı bir değiştirmenin tersi.

Tedarikçi bağımlılığı, bir müşterinin tek bir tedarikçinin tescilli teknolojisine, veri biçimlerine ya da sözleşme koşullarına o kadar bağımlı hâle gelmesi, başka bir tedarikçiye geçmenin yasaklayıcı maliyet ya da risk taşımasıdır. Tedarikçi bağımlılığı, kamu sektörü yazılımında özel bir tehlikedir, çünkü alıcı kritik bir hizmeti yürüten bir sistemden ayrılma konusunda sınırlı pratik yeteneği olan tekrar eden bir müşteridir; bu her sonraki yenilemede pazarlık konumunu zayıflatır.

Özgür ve açık kaynak yazılım, kullanıcılara kaynak kodunu kullanma, inceleme, değiştirme ve yeniden dağıtma özgürlüğü veren bir lisans altında dağıtılan yazılımdır. Özgür ve açık kaynak yazılım, bir kamu kuruluşunun, belirli bir neden — güvenlik hassasiyeti, üçüncü taraf hakları — saklamayı haklı çıkarmadıkça görevlendirdiği kaynak kodunu yayımlamayı varsayılan yaptığı bir varsayılan olarak açık kaynak politikasının temelini oluşturur; gerekçe genellikle "kamu parası, kamu kodu" olarak özetlenir: kamu fonlarıyla bir kez ödenmiş yazılımın, aynı sorunu çözen farklı bir kamu kuruluşu tarafından farklı bir yargı alanında yeniden ödenmesi gerekmemelidir.

Dijital bir kamusal mal, ticari bir getiri üretmek yerine bir kamusal kalkınma ya da yönetişim hedefini karşılamaya yardım etmek üzere tasarlanmış, açık bir lisans altında yayımlanmış açık yazılım, veri veya içeriktir. Dijital kamusal mallar, bir hükümetin açık kaynak sürümünü yalnızca dahili bir şeffaflık jesti değil diğer hükümetlerin ve sivil toplum kuruluşlarının doğrudan yararlanabileceği daha geniş, paylaşılan bir altyapının parçası olarak yeniden çerçeveler.

Çevik yazılım geliştirme, önceden kararlaştırılmış sabit bir planı izlemek yerine çalışan yazılımı, sık teslimi ve değişime yanıt vermeyi tercih eden, yazılım inşa etmeye yönelik yinelemeli yaklaşımlar için bir şemsiye terimdir. Çevik yazılım geliştirme, gereksinimlerin, tasarımın, inşanın ve sınamanın her birinin bir sonraki başlamadan önce tam olarak tamamlandığı ardışık bir yaklaşım olan şelale modeline karşıt durur; şelalenin kamu kuruluşları için çekiciliği her zaman kilometre taşlarının sabit fiyatlı bir sözleşmeye ve yıllık bir bütçe döngüsüne düzgünce eşlenmesi olmuştur; teslim gerçekten çevik olduğunda bile kamu alımları hukukunun bu kadarının hâlâ onu varsaymasının nedeni budur.

Asgari uygulanabilir ürün, bir hizmetin işleyip işlemediğini sınamak ve sırada neyi inşa edeceğini öğrenmek için gerçek kullanıcılara yayımlanabilen en küçük sürümüdür. Kamu sektörü dijital hizmet oyun kitaplarına uyarlanan asgari uygulanabilir ürün kavramı, yinelemeli bir ekibe bir fon sağlayıcıya ya da bir denetçiye tam kapsam tamamlanmadan çok önce gerçek ve çalışan bir şey gösterme konusunda savunulabilir bir yol verir — hesap verebilirlik sürecinin gerçekten asgari bir sürümü kabul etmesi, onu başka bir adla bitmiş ürün olarak görmemesi koşuluyla.

İyi uygulamalar

Ayırt edici olmayan ihtiyaçlar için satın almayı varsayılan yapın ve inşa etmeyi gerçekten ayırt edici olana saklayın. Bordro, e-posta ve genel vaka yönetimi ihtiyaçları, ısmarlama yazılımı haklı çıkaracak kadar başka herhangi bir kuruluşunkinden nadiren farklıdır; yalnızca gereksinim, ölçek ya da yeteneğe onlarca yıl sahip olma ve onu geliştirme ihtiyacı piyasanın sunduğundan gerçekten farklı olduğunda inşa edin.
Ne kadarını taşıyacağınıza karar vermeden önce teknik borcu görünür kılın. Hizmetteki her sistem için bilinen kestirmelerin, ertelenmiş düzeltmelerin ve desteklenmeyen bağımlılıkların bir kaydını tutun, sabit bir döngüde gözden geçirin; böylece borcu bir yıl daha taşımak kimsenin bakmaması değil kasıtlı bir ödünleşim olur.
Kritik bir eski sistemden çıkışın tek yolu olarak tek, geri döndürülemez bir geçişi asla planlamayın. Her parçanın sınanmasına, tersine çevrilmesine ve kademeli yaygınlaştırılmasına izin veren boğucu incir örüntüsü gibi artımlı yaklaşımları tercih edin; milyonların bağımlı olduğu bir sistemin büyük patlamalı değiştirilmesi, yıllarca riski tek bir hafta sonuna yoğunlaştırır ve bir şey başarısız olursa geri dönüş yolu yoktur.
Kuruluşunuzun yazdırmak için para ödediği kaynak kodunu kiraladığı bir hizmet değil sahip olduğu bir varlık olarak ele alın. Kaynak kodu emanetini ya da doğrudan sahipliği bir anlaşmazlık başladıktan sonra değil sözleşme anında müzakere edin, çünkü kritik hizmetinizin kodunun tek kopyasını elinde tutan bir tedarikçi tasarım gereği tedarikçi bağımlılığıdır.
Kaynak kodunu varsayılan olarak açık yayımlayın ve saklamak için belirli bir gerekçe isteyin. Tutarlı uygulanan bir varsayılan olarak açık kaynak politikası, her bölümün özel yapım yazılımını tek seferlik bir maliyet yerine paylaşılan bir bakanlıklar arası varlığa dönüştürür ve dış uzmanların yalnızca kurum içi bir ekibin kaçıracağı güvenlik açıklarını bulmasına izin verir.
Yazılım sözleşmelerini yinelemeli teslimi yalnızca teknik olarak mümkün değil yasal kılacak biçimde yazın. Yalnızca imza anında kararlaştırılmış sabit bir belirtime karşı ödeyen bir sözleşme, bir ekibi dürüst çevik pratik ile sözleşmeye uyum arasında seçim yapmaya zorlar; bunun yerine sonda tek bir kilometre taşı yerine gösterilen çalışan yazılıma bağlı aşamalı fonlama kapıları kullanın.
Modernizasyonu tek seferlik bir sermaye projesi değil süregelen bir program olarak fonlayın. Bir kez modernize edilip yirmi yıl daha bırakılan bir eski sistem, başladığı aynı riski biriktirir; bir yol idaresinin yeniden kaplamayı bütçelediği gibi sürekli, artımlı yenilenmeyi bütçeleyin, bir kuşakta bir kez büyük bir değiştirmeyi değil.
Ticari yazılım satın alırken bile açık standartları ve taşınabilir veri biçimlerini seçin. Bir tedarikçinin sisteminin veriyi açık, belgelenmiş biçimlerde saklamasını ve dışa aktarmasını gerektirmek, yazılımın kendisi tescilli olsa bile geçiş maliyetlerini düşük tutar ve çoğu zaman her sistemin açık kaynak olmasında ısrar etmekten tedarikçi bağımlılığına karşı daha ulaşılabilir bir yakın vadeli güvencedir.
Tam kapsama taahhüt etmeden önce asgari uygulanabilir bir ürün inşa edin ve gerçek kullanıcılara gösterin. Gerçekten asgari bir sürümü yayımlayıp öğrenilenler üzerinden yinelemek, yanlış varsayımları hâlâ düzeltmesi ucuzken yakalar, tam ölçekli bir sistem onlara karşı inşa edildikten sonra değil.
Hizmet teslimi dışarıya devredilse bile, akıllı bir alıcı olmak için yeterli kurum içi mühendislik yeteneğini koruyun. Teknik uzmanlığını boşaltmış bir kamu kuruluşu bir tedarikçinin teklifini değerlendiremez, sorunlu bir projenin erken uyarı işaretlerini fark edemez ya da kâğıt üzerinde alım kuralları ne derse desin bağımlılıktan çıkış için pazarlık edemez.
Bir eski sistemin risk profilini kullanıcı arayüzünden önce emekliye ayırın. Desteklenmeyen dilleri, yamasız altyapıyı ve belgelenmemiş entegrasyonları — kesintilere ve ihlallere yol açan başarısızlıkları — çok daha az operasyonel risk taşıyan görsel modernizasyondan önce değiştirmeye öncelik verin.
Teslim sağlığını yalnızca bütçe ve takvim varyansıyla değil mühendislik göstergeleriyle ölçün. Dağıtım sıklığı, kusur oranları ve en eski ele alınmamış teknik borç kaleminin yaşı, bir yönetim kuruluna bir programın başarılı olup olmayacağı hakkında, hareket eden son gösterge olan bütçe dahilinde olup olmadığından çok daha fazlasını söyler.

Ekibinizle tartışılacak sorular

Sistem sistem ne kadar teknik borç taşıdığımızı gerçekten biliyor muyuz? Çoğu kamu kuruluşu yıllık sermaye bütçesini belirtebilir ama yazılım varlığının ne kadarının desteklenmeyen bileşenlerde, belgelenmemiş mantıkta ya da kadroda kalan hiç kimsenin tam anlamadığı kodda çalıştığını güvenle belirtemez. Bu soruyu, odadaki her sistem sahibinden, ekiplerinin en kritik sistemini kimsenin öngörmediği bir şeyi bozmadan güvenle değiştirebileceğinden ne kadar emin olduklarını dürüstçe tahmin etmesini istemek için kullanın. Bu tahminleri kilit bir mühendis ayrıldığında giden kabile bilgisi yerine sabit bir döngüde gözden geçirilen gerçek bir kayda dönüştürmenin neyi gerektireceğini tartışın. Ayrıca şu anda ne kadar borç taşımanın kabul edilebilir olduğuna kimin karar verdiğini ve bu kararın kasıtlı mı yoksa varsayılan olarak mı alındığını düşünün.

En kritik eski sistemimiz bugünden itibaren değiştirilmek zorunda olsaydı, büyük patlamalı bir geçiş mi yoksa artımlı bir göç mü planlıyor olurduk — ve neden? Eski bir sistemi bir anda değiştirme içgüdüsü çoğu zaman teknik zorunluluktan çok bütçe döngüleri ve program yönetimi kolaylığıyla yönlendirilir ve muazzam riski tek bir ana yoğunlaştırır. Bu soruyu, en kritik eski sisteminizin boğucu incir tarzı artımlı göçünün parça parça gerçekte neye benzeyeceğini somut olarak adım adım gözden geçirmek için kullanın. Sizi bugün bu yolu seçmekten neyin alıkoyduğunu tartışın — tek bir canlıya geçiş tarihi etrafında yapılandırılmış fonlama, tek bir temiz kilometre taşı isteyen bir yönetişim süreci ya da bu sistem için artımlı göçü imkânsız kılan gerçek bir teknik kısıt.

Kuruluşumuzun yazdırmak için para ödediği yazılımın kaynak kodunun sahibi kim ve bunu kanıtlayabilir miydik? Birçok kamu kuruluşu, yalnızca bir tedarikçiyle ilişkisi bozulduğunda, sözleşmenin kritik hizmetlerinin bağımlı olduğu kodun net sahipliğini ya da emanetini hiç güvence altına almadığını keşfeder. Bu soruyu, en önemli üç ısmarlama sisteminizin sözleşmelerini çekmek ve her birinin kod sahipliği, emanet ve kodu başka bir tedarikçiye götürme hakkı hakkında özellikle ne dediğini kontrol etmek için kullanın. Bu üç sistemden herhangi biri için birincil tedarikçiniz yarın iflas etse ya da ilişkiyi sürdürmeyi reddetse ne olacağını tartışın.

Varsayılan olarak açık kaynak yaklaşımının bize aynı derecede iyi ya da daha iyi hizmet edeceği yerde, nerede alışkanlıktan kapalı, tescilli yazılıma varsayılan olarak başvuruyoruz? Varsayılan olarak açık kaynak politikaları tam da çoğu kamu kuruluşunun örtüşen sorunları bağımsız çözmesi, her birinin başka bir kamu kuruluşunun zaten inşa ettiği ve paylaşabileceği yazılımın tam maliyetini ödemesi nedeniyle vardır. Bu soruyu, şu anda inşa edilen ya da belirtilen bir sistemi belirlemek ve hükümette başka yerde açık kaynak yazılım olarak eşdeğerinin zaten var olup olmadığını ya da inşa ettiğinizin başkalarının yeniden kullanması için yararlı biçimde yayımlanıp yayımlanamayacağını sormak için kullanın. Burada ilgili olmadığını varsaymak yerine o yeniden kullanımı gerçekte hangi belirli engelin — güvenlik kaygısı, alım alışkanlığı, net bir politika eksikliği — durdurduğunu tartışın.

Alım ve hesap verebilirlik sürecimiz gerçekten dürüst çevik teslime izin veriyor mu, yoksa yalnızca şelale kilometre taşlarını sprint olarak mı yeniden etiketliyor? Bir ekibin nominal olarak çevik törenler yürütürken yine de sözleşme imzasında kararlaştırılmış sabit bir belirtime karşı fonlanması, yönetilmesi ve raporlanması yaygındır; bu, her şelale başarısızlık biçimini çevik bir etiket altında yeniden yaratır. Bu soruyu, canlı bir dijital programı iş gerekçesinden mevcut yönetişim raporlamasına kadar izlemek ve fonlama yapısının programın gerçek bir erken sürümün öğrettiklerine dayanarak yön değiştirmesine tahammül edip etmeyeceğini sormak için kullanın. Yinelemeli teslimin kozmetik değil gerçek olması için programın nasıl fonlandığında ve raporlandığında neyin değişmesi gerektiğini tartışın (bkz. Konu 3.7 — Kamu Alımları ve Hizmet Tedariki).

En çok bağımlı olduğumuz sistemlerin akıllı bir alıcısı olmak için yeterli kurum içi mühendislik yeteneğimiz var mı? Yalnızca teslim kapasitesini değil tüm teknik yargısını dışarıya devretmiş bir kuruluş, bir tedarikçinin teklifinin sağlam olup olmadığını, bir projenin sessizce belaya doğru gidip gitmediğini ya da işin adil fiyatının ne olduğunu söyleyemez. Bu soruyu, kuruluşunuzda en önemli sisteminiz için bir teknik mimari önerisini inandırıcı biçimde gözden geçirebilecek kaç kişinin olduğunu ve bu sayının son beş yılda nasıl değiştiğini sormak için kullanın. Aşındığı yerde o yeteneği yeniden inşa etmenin neyi gerektireceğini ve kuruluşunuzun onsuz geçen her yıl için pazarlık konumunda olduğu kadar teslim riskinde de neyi kaybettiğini tartışın.

Uygulamada: bir kamu değeri örneği

Kurgusal bir bölgesel hükümet — yalnızca örnek, herhangi bir gerçek yargı alanının tarifi değil — işsizlik yardımı taleplerini otuz yıldan fazla önce ilk yazılmış, orijinal programlama dilini anlayan giderek azalan sayıda mühendisin sürdürdüğü bir sistem aracılığıyla yürütüyordu. Talep hacmi sistemin tasarımcılarının öngördüğünün çok ötesine büyümüştü, gecelik işleme çalıştırmaları sabah işlemleri başlamadan önce giderek daha sık tamamlanamıyordu ve idarenin teknoloji liderliği, yardım ödemelerini etkileyen plansız bir kesintinin artık olup olmama değil ne zaman olacağı meselesi olduğu konusunda uyarıyordu.

İdarenin ilk içgüdüsü acil hissettiren bir soruna geleneksel bir yanıttı: tüm sistemi baştan belirtilen, sonunda tek geçiş hafta sonu olan sabit iki yıllık bir takvime karşı teslim edilecek modern bir platformla değiştirmek için tek büyük bir sözleşme görevlendirmek. İdarenin denetim komitesinin görevlendirdiği bir uygulama öncesi gözden geçirme, sözleşme imzalanmadan önce zor bir soru sordu: yeni sistemin tam ölçekli, canlı işletmesinin ilk haftasında keşfedilmemiş bir kusuru olsa ve eski sistem zaten devre dışı bırakılmış, geri dönüş yolu olmasa, birkaç yüz bin başvuru sahibinin yardım ödemelerine ne olurdu.

İdare rotasını değiştirdi. Eski sistemi kayıt sistemi olarak çalışır tuttu ve boğucu incir yaklaşımını kullanarak yanında yeni talep alma ve uygunluk değerlendirme işlevselliği inşa etmeye başladı: her yeni modül önce yeni taleplerin küçük bir yüzdesine yayımlandı, eski sistemin paralel çıktısına karşı doğrulandı ve ancak sonuçları eşleştiğinde genişletildi. On sekiz ay içinde yeni taleplerin çoğu modern bileşenlerden geçiyordu, orijinal sistem ise küçülen bir artık vaka yükünü ele alıyordu; bir şey yanlış görünürse herhangi bir tek vakayı eski yola geri yönlendirme yeteneğiyle. İdare ayrıca bu iş için yayımlanan her yeni sözleşmede kaynak kodunun idarenin sahipliğinde olmasını ve güvenlik incelemesi tamamlandıktan sonra açık kaynak olarak yayımlanmasını şart koştu; böylece aynı eskiyen ana bilgisayar sorunuyla karşılaşan diğer bölgesel hükümetler aynı inşayı sıfırdan tekrarlamak yerine bileşenleri uyarlayabilirdi.

Eski sistemin son artık işlevlerinin tam değiştirilmesi neredeyse dört yıl aldı — kâğıt üzerinde özgün iki yıllık büyük patlamalı planın vaat ettiğinden uzun. Ama hiçbir başvuru sahibi geçiş sırasında hiç plansız bir kesinti yaşamadı, her artış bir kusur bulunduğunda saatler içinde geri alınabilecek kadar küçüktü ve iki komşu bölgesel hükümet, idarenin yayımlanmış uygunluk değerlendirme kodunu kendi sistemleri için yayımlandıktan sonraki ilk yıl içinde uyarlamaya başladı.

Dört sektör bakışı

Yerel yönetim

Yerel yönetim tipik olarak az sayıda ulusal ölçekli platform yerine çok sayıda daha küçük, bağlantısız sistem yürütür; bu da teknik borcun tek bir görünür amiral gemisi sistemde değil ayrı ayrı satın alınmış, ayrı ayrı bakımı yapılan birçok uygulamada biriktiği anlamına gelir. Yerel yönetimler genellikle hükümetin herhangi bir kademesinin en az kurum içi mühendislik yeteneğine sahiptir; bu da yapılandırılabilir meta yazılımı ısmarlama inşalara tercih etme gerekçesini özellikle güçlü kılar ve Konu 5.1'in konusu olan paylaşılan bölgesel veya ulusal platformları (bkz. Konu 5.1 — Dijital Devlet ve Dijital Dönüşüm) her idarenin aynı yeteneği ayrı ayrı yeniden inşa etmesinden kaçınmak için özellikle yüksek değerli bir yol yapar.

Merkezi yönetim

Merkezi yönetim, en eski ve en sonuç doğurucu eski sistemlerin — çekirdek vergi, sosyal sigorta ve yardım yönetimi — genellikle bulunduğu yerdir, çünkü bunlar çoğu zaman hükümetteki ilk büyük ölçekli bilgisayarlaştırma çabalarındandı ve şimdi herhangi bir modernizasyon başarısızlığı için en yüksek riskleri taşır. Merkezi yönetim tipik olarak gerçekten artımlı bir modernizasyon programı yürütmek ve sözleşmelerine gerçek kod sahipliğini müzakere etmek için uzman ticari ve mühendislik yeteneğine sahiptir ve çoğunlukla çapraz hükümet yeniden kullanımını gerçekten gerçekleştirmeye yetecek ölçekle varsayılan olarak açık kaynak politikasını belirlemek için en iyi konumdaki hükümet kademesidir.

Sosyal sektör ve kâr amacı gütmeyen kuruluşlar

Kâr amacı gütmeyen kuruluşlar ve hayır kurumları nadiren kendileri büyük özel platformlar inşa eder, ama sıklıkla bir hükümet fon sağlayıcısı tarafından görevlendirilen ya da zorunlu kılınan yazılımın alıcı tarafındadır — bir raporlama portalı, bir hibenin veya sözleşmenin kullanmalarını gerektirdiği bir vaka yönetimi sistemi — tasarımı, teknik borcu veya tedarikçisi üzerinde çok az etkiyle. Hükümetçe zorunlu kılınan bir sisteme bağımlı bir sosyal sektör kuruluşu, o sistemin başarısızlık biçimlerini onları düzeltmek için hiçbir kaldıraç devralmadan devralır; bu, sonuç temelli fonlama ilişkilerinin yalnızca sonuç ölçütünü değil zorunlu kılınan teknolojinin operasyonel yükünü de hesaba katması gerektiğinin bir sebebidir (bkz. Konu 3.7 — Kamu Alımları ve Hizmet Tedariki).

Çok taraflı ve uluslararası

Çok taraflı kuruluşlar ve kalkınma kurumları, bir ülkenin kamu yönetimi için inşa edilmiş yazılımı, her hükümetin özel bir tedarikçiden tam maliyetle eşdeğer bir sistem görevlendirmesi yerine diğer ülkelerin uyarlayabileceği yeniden kullanılabilir bir dijital kamusal mal olarak giderek daha fazla teşvik eder. Buradaki ayırt edici risk, bir ülkenin yasal ve idari bağlamı için inşa edilmiş bir dijital kamusal malın başka yerde çok az uyarlamayla benimsenebilmesi ve kimlik, uygunluk ya da süreç hakkında gerçekte aktarılmayan varsayımları ithal etmesidir; paylaşılan, açık altyapının vaadi gerçektir, ama yalnızca gerçek yerel uyarlama kapasitesi kodla birlikte geldiği yerde.

Sık görülen başarısızlık biçimleri

Canlıya geçişte başarısız olan büyük patlamalı geçiş. Kritik bir eski sistem, canlı üretim maruziyeti olmadan yıllarca geliştirmeden sonra tek, geri döndürülemez bir geçişle değiştirilir ve yalnızca gerçek ölçekte ya da kimsenin sınamadığı bir uç durumda ortaya çıkan bir kusur, tam işletmenin ilk gününde yüzeye çıkar; eski sistem zaten devre dışı bırakıldığı için ona geri dönme yolu yoktur. Maliyet, kaçırılan ödemeler, reddedilen hizmetler ya da sistemin hizmet etmek için var olduğu yurttaşları etkileyen kesintilerle, mümkün olan en kötü anda — herkesin değiştirmenin çalışmasına güvendiği anda — ölçülür.

Sessiz teknik borç birikimi. Son tarih baskısı, bilinen kestirmeleri düzeltmek için gereken zamana karşı argümanı tekrar tekrar kazanır ve her erteleme tek başına savunulabilirdir; birikmiş borç en küçük bir değişikliği bile orantısız biçimde pahalı ve riskli kılana kadar. Maliyet yıllar sonra kimsenin güvenle değiştiremeyeceği bir sistem, yalnızca en acil yamalardan başka hiçbir şeyi denemeyi sessizce bırakmış bir iş gücü ve sürekli, daha küçük bir yenilemenin olacağından çok daha büyük ve pahalı bir nihai modernizasyon programı olarak ortaya çıkar.

İstikrar sanılan tedarikçi bağımlılığı. Bir kamu kuruluşu aynı tedarikçinin sözleşmesini, geçmek denemek için fazla aksatıcı göründüğü için, gerçek geçiş maliyetlerinin ne olacağını hiç sınamadan ya da bu maliyetleri yönetilebilir tutacak kod sahipliği ve açık veri biçimleri için pazarlık etmeden tekrar tekrar yeniler. Maliyet, fiyat ve koşullar üzerinde kalıcı olarak zayıflamış bir pazarlık konumudur; yalnızca tedarikçinin hizmet kalitesi düştüğünde ya da fiyatları yükseldiğinde ve kamu kuruluşu inandırıcı bir alternatifi olmadığını bulduğunda keşfedilir.

Kozmetik çeviklik. Bir teslim ekibi çevik törenleri — günlük toplantılar, sprintler, bir iş listesi — benimser, altta yatan sözleşme, fonlama ve yönetişim yapısı ise hâlâ sabit bir belirtimi ve tek bir devam/dur kilometre taşını varsayar; böylece ekip sprint hızını raporlar ama altta fiilen bir şelale planına karşı teslim eder. Maliyet, çevikliğin gerçek yararlarının hiçbirinin — yönü değiştiren erken kullanıcı geri bildirimi, erken ortaya çıkan risk — gerçekleşmemesi, modern pratik görünümünün ise altta yatan katılığı gözetim organlarının görmesini ve itiraz etmesini zorlaştırmasıdır.

Sürdürülebilirlik planı olmayan açık kaynak politikası. Bir kamu kuruluşu bir varsayılan olarak açık kaynak politikasını karşılamak için kaynak kodunu yayımlar, ama yayımı dış katkıları gözden geçirmek, güvenlik açıklarını yamamak ya da belgeleri sürdürmek için kaynak ayrılmadan tek seferlik bir uyum adımı olarak ele alır. Maliyet, açık görünen ama bakımsız bir çıkmaz sokak olarak işleyen yayımlanmış bir depodur; bu, hiç yayımlamamaktan daha çok daha geniş varsayılan olarak açık kaynak programına güvene zarar verir.

Olgunluk modeli

Alt boyut	Başlatma	Geliştirme	Standartlaştırma	Yönetme	Eşgüdüm
Teknik borç görünür ve yönetilir	Borç belgelenmemiştir ve yalnızca bireysel mühendislerce gayriresmî bilinir	Bazı sistemler için kısmi bir envanter vardır, sabit bir döngüde gözden geçirilmez	Bir borç kaydı tüm kritik sistemleri kapsar ve belgelenmiş bir döngüde gözden geçirilir	Borç azaltma fonlanır ve ölçülebilir hedeflere karşı izlenir	Borç verisi modernizasyon yatırımını önceliklendirmek için kuruluşun tüm varlığı boyunca paylaşılır
Eski sistem modernizasyonu büyük patlama riskinden kaçınır	Değiştirme tek bir tam yeniden yazım ve geçiş anlamına geldiği varsayılır	Artımlı yaklaşımlar ara sıra, tutarlı bir yöntem olmadan kullanılır	Boğucu incir tarzı artımlı göç kritik sistemler için belgelenmiş varsayılandır	Göç ilerlemesi ve geri alma hazırlığı etkin biçimde ölçülür ve raporlanır	Modernizasyon yöntemi ve araçları emsal kamu kuruluşları arasında paylaşılır ve iyileştirilir
İnşa et–satın al kararları kasıtlıdır	İnşa etme ya da satın alma alışkanlık ya da tedarikçi ilişkisiyle seçilir, değerlendirilmez	Büyük yazılım kararlarından önce bir miktar değerlendirme, tutarsız biçimde yapılır	Belgelenmiş bir karar çerçevesi her önemli inşa et–satın al seçimine uygulanır	İnşa et–satın al sonuçları zaman içinde özgün gerekçelerine karşı izlenir	İnşa et–satın al yeteneği ve dersleri aynı seçimle karşılaşan diğer kamu kuruluşlarıyla paylaşılır
Kaynak kodu ve veri varsayılan olarak açıktır	Kapalı, tescilli teslim sorgulanmayan varsayılandır	Açık kaynak yayımı ara sıra, bireysel ekiplerce yönlendirilir	Varsayılan olarak açık kaynak politikası belgelenmiş ve tutarlı uygulanmıştır	Yayımlanan kod dış katkılar için kaynakla etkin biçimde sürdürülür	Yayımlanan kod hükümet genelinde ve diğer yargı alanlarınca yeniden kullanılır, yeniden kullanım bir yarar olarak izlenir
Teslim yöntemi hesap verebilirlik yapısına uyar	Sözleşmeler ve yönetişim, teslim gerçekte nasıl gerçekleşirse gerçekleşsin şelaleyi varsayar	Çevik törenler kullanılır, ama fonlama ve yönetişim hâlâ sabit bir belirtimi kapı olarak kullanır	Sözleşmeler ve fonlama kapıları gösterilen çalışan yazılım etrafında yapılandırılmıştır	Teslim sağlığı yalnızca bütçe ve takvim varyansıyla değil mühendislik göstergeleriyle ölçülür	Alım ve hesap verebilirlik kuralları kanıta dayalı olarak yinelemeli teslime uyacak biçimde etkin biçimde uyarlanır

Kontrol listesi

Her kritik sistemin teknik borcunu envanterleyin ve kaydı sabit bir döngüde gözden geçirin.
Herhangi bir önemli yeni yazılıma taahhüt etmeden önce belgelenmiş bir inşa et–satın al çerçevesi uygulayın.
Herhangi bir eski sistem değiştirmesi için artımlı bir göç yöntemini varsayılan yapın ve büyük patlamalı bir geçiş için açık bir gerekçe isteyin.
İmzadan önce her yazılım sözleşmesinde kaynak kodu sahipliği ya da emanet koşullarını doğrulayın.
Belgelenmiş bir istisna süreciyle varsayılan olarak açık kaynak politikası altında kaynak kodunu yayımlayın.
Bu politika altında yayımlanan her depo için yalnızca ilk sürümünü değil süregelen bakımı da kaynaklandırın.
Altta yatan yazılım tescilli olsa bile açık, belgelenmiş veri biçimleri talep edin.
Fonlama kapılarını tek bir sabit belirtim kilometre taşı yerine gösterilen çalışan yazılım etrafında yapılandırın.
Tam kapsama taahhüt etmeden önce gerçek kullanıcılarla asgari uygulanabilir bir ürün inşa edin ve sınayın.
Dağıtım sıklığını, kusur oranlarını ve ödenmemiş teknik borcu kalıcı yönetişim göstergeleri olarak izleyin.
Kurum içi mühendislik yeteneğini akıllı bir alıcı olmak için gerekenlere karşı değerlendirin ve belirlenen boşlukları kapatın.
Desteklenmeyen altyapıya ve belgelenmemiş entegrasyonlara kozmetik modernizasyondan önce öncelik verin.

Temel kaynaklar

GOV.UK Service Standard, Government Digital Service, Birleşik Krallık — kamu hizmetleri için yinelemeli, kullanıcı merkezli teslim ve açık standartlar gerektiren ulusal bir dijital hizmet standardı.
Office of Management and Budget, Federal Source Code Policy (M-16-21), Amerika Birleşik Devletleri — kurumların özel geliştirilmiş hükümet yazılımı için yeniden kullanımı ve açık kaynak yayımını dikkate almasını gerektiren federal politika.
Free Software Foundation Europe, Public Money, Public Code kampanyası — kamu fonlu yazılım kaynak kodunun özgür ve açık kaynak lisanslar altında yayımlanması için Avrupa kitlesi için geliştirilmiş gerekçe.
Ward Cunningham, "The WyCash Portfolio Management System" (OOPSLA 1992 deneyim raporu) — teknik borç metaforunun özgün ifadesi.
Digital Public Goods Alliance — kamusal kalkınma hedeflerine hizmet etmek üzere tasarlanmış açık yazılım, veri ve içerik için standartlar ve bir kayıt tutan çok paydaşlı bir girişim.

Kaynakça

Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
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/
Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
"The WyCash Portfolio Management System" (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
Digital Public Goods Alliance — https://digitalpublicgoods.net/