Avaliku sektori tarkvaraarendus ja platvormid

Miks see avaliku väärtuse jaoks oluline on

Peaaegu iga avalik teenus, millega kodanik täna kokku puutub – sünni registreerimine, toetuse taotlemine, maksuarve tasumine, kohtuaja broneerimine –, töötab kuskil leti või ekraani taga tarkvaral. See tarkvara on harva ühekordne ost; see saab osaks riigi püsivast taristust, mis sageli elab üle administratsiooni, mis selle tellis, tarnija, mis selle ehitas, ja programmeerimiskeele, milles selle insenere koolitati. Avalik organ ei koge tarkvara nii, nagu ta koge hoonet või teed, kus vara seisukord on nähtav; tarkvara laguneb nähtamatult ja selle lagunemise arve saabub aastaid hiljem hädaolukorrana.

Selle teema aluseks olev pinge on struktuurne. Tarkvara on olemuslikult iteratiivne – nõuded selgenevad, kui kasutajad töötava süsteemiga suhtlevad, ning parim inseneripraktika on ehitada midagi väikest, õppida ja kohaneda. Avalikud hanke- ja vastutustsüklid (vt Teema 3.7 — Riigihanked ja tellimine) on seevastu ehitatud kapitalitööde ja kaitselepingute jaoks: fikseeritud spetsifikatsioon, üks suur pakkumisotsus, vahe-eesmärkide maksed ja ärijuhtum, mis on kinnitatud aastaid enne tarne algust. Kui seadusandja või audiitor ootab fikseeritud hinnaga, fikseeritud ulatusega lepingut ja inseneride meeskond peab pärast esimest väljalaset suunda muutma, ilmneb lahknevus ulatuse hiilimisena, eelarve ületamisena või süsteemina, mis oli 2019. aastal õigesti täpsustatud ja osutub aegunuks ajaks, kui see valmis saab.

Platvormid, mille ehitamiseks selle teema inseneripraktika on olemas – jagatud isikutuvastussüsteemid, maksekanalid, osakondade vahel taaskasutatavad juhtumikorralduse tööriistad –, on teema 5.1 aine (vt Teema 5.1 — Digitaalne valitsemine ja digitaalne ümberkujundamine); see teema käsitleb distsipliini, kuidas ehitada ja osta tarkvara, mis teeb iga sellise platvormi või iga üksiku teenuse usaldusväärseks, asendatavaks ja avaliku organi omandis, kes sellest sõltub, mitte omandis tarnija käes, kes selle juhuslikult esimesena kirjutas.

Põhimõisted

Ehita-versus-osta otsus on valik tellida ühe organisatsiooni vajaduse jaoks kirjutatud eritarkvara või võtta kasutusele seadistatav kaubatarkvara, mis on juba ehitatud sarnaste ostjate turu jaoks. Ostmine on tavaliselt odavam ja madalama riskiga vajaduse jaoks, mis ei ole tõeliselt eristuv – palgaarvestus, e-post, standardne juhtumikorraldus –, samal ajal kui ehitamine on õigustatud ainult seal, kus nõue on piisavalt erinev, et ükski seadistatav toode ei sobi, või kus suutlikkus ise on strateegiline vara, mida organisatsioon peab omama ja arendama.

Tehniline võlg on metafoor, mille lõi tarkvarainsener Ward Cunningham 1992. aastal, kuhjunud kulule, mis tuleneb ratsionaalse viisi valimisest tarkvara praegu välja anda kuni põhjalikuma viisini, mis oleks võtnud kauem aega. Tehniline võlg ei ole nagu rahaline võlg olemuslikult vale peale võtta – Cunninghami enda mõte oli, et töötava koodi kiire väljastamine ja hilisem ümberstruktureerimine võib olla õige otsus –, kuid võlg, mida kunagi ei tagastata, kogub intressi aeglasema tarne, rohkemate defektide ja kasvava riskina ning avalik organ, kes ei näe oma võlga, ei saa otsustada, kas seda teenindada või lasta sellel kuhjuda.

Pärandsüsteem on vana tehnoloogia, rakendus või platvorm, mis on aktiivses kasutuses vaatamata aegumisele, sageli seetõttu, et selle asendamine on kallis või kuna keegi organisatsioonis ei mõista täielikult, mida see teeb. Pärandsüsteemid on valitsuses eriti püsivad: aastakümneid tagasi kirjutatud põhilised maksu-, toetuste ja sotsiaalkindlustuse süsteemid keeltes nagu COBOL – Common Business-Oriented Language, kavandatud 1960. aastal halduslikuks andmetöötluseks – töötlevad endiselt tehinguid miljonite kodanike jaoks, sest süsteemid töötavad ja institutsionaalne teadmine, mida on vaja nende ohutuks pensionile saatmiseks, on sageli ise esimesena pensionile läinud.

Tarkvara moderniseerimine on üldmõiste pärandsüsteemi teisendamiseks, ümberkirjutamiseks või migreerimiseks praegusele arhitektuurile, keelele või platvormile. Tarkvara moderniseerimine ulatub täielikust ümberkirjutamisest konservatiivsemate võimalusteni, nagu sama koodi ümberpaigutamine kaasaegsele taristule, ning valik nende vahel on sama palju riskijuhtimise kui tehniline otsus.

Kägistajaviigipuu muster on järkjärguline moderniseerimise lähenemine, mis on nime saanud viinapuu järgi, mis kasvab peremeespuu ümber ja asendab selle järk-järgult, milles uus funktsionaalsus ehitatakse pärandsüsteemi kõrval ja liiklus suunatakse sellele tükikaupa, mitte ei asendata kogu süsteemi ühe üleminekuga. Kägistajaviigipuu muster on oluline, sest see laseb iga juurdekasvu testida, tagasi pöörata või peatada, kogu teenust maha võtmata – vastupidine suurpauk-asendusele, kus vana süsteem lülitatakse välja ja uus sisse ühel hetkel ilma teed tagasi, kui midagi on valesti.

Tarnijasõltuvus tekib, kui klient muutub nii sõltuvaks ühe tarnija patenteeritud tehnoloogiast, andmevormingutest või lepingutingimustest, et teisele tarnijale ülemineku kulu või risk on keelav. Tarnijasõltuvus on avaliku sektori tarkvaras eriline oht, sest ostja on püsiklient, kellel on piiratud praktiline võime kriitilist teenust käitavast süsteemist ära kõndida, mis nõrgendab tema läbirääkimispositsiooni igal järgneval pikendamisel.

Vaba ja avatud lähtekoodiga tarkvara on tarkvara, mida levitatakse litsentsi all, mis annab kasutajatele vabaduse lähtekoodi kasutada, uurida, muuta ja edasi levitada. Vaba ja avatud lähtekoodiga tarkvara toetab vaikimisi avatud lähtekoodi poliitikat, mille all avalik organ avaldab vaikimisi lähtekoodi, mille ta tellib, kui just konkreetne põhjus – turvatundlikkus, kolmandate isikute õigused – ei õigusta selle tagasihoidmist; põhjendus võetakse tavaliselt kokku sõnadega „avalik raha, avalik kood": tarkvara, mille eest on kord avaliku rahaga makstud, ei tohiks vaja olla uuesti osta, teises jurisdiktsioonis, teise avaliku organi poolt, kes lahendab sama probleemi.

Digitaalne avalik hüve on avatud tarkvara, andmed või sisu, välja antud avatud litsentsi all, kavandatud aitama saavutada avalikku arengu- või valitsemiseesmärki, mitte teenima kommertstulu. Digitaalsed avalikud hüved raamivad ühe valitsuse avatud lähtekoodiga väljalaske osana laiemast jagatud taristust, millele teised valitsused ja kodanikuühiskonna organisatsioonid saavad otse tugineda, mitte ainult sisemise läbipaistvuse žestina.

Agiilne tarkvaraarendus on kokkuvõttev termin tarkvara ehitamise iteratiivsete lähenemiste jaoks, mis eelistavad töötavat tarkvara, sagedast tarnet ja muutustele reageerimist ette kokku lepitud fikseeritud plaani järgimisele. Agiilne tarkvaraarendus seisab vastandina koskmudelile (waterfall), järjestikusele lähenemisele, kus nõuded, kavand, ehitus ja testimine lõpetatakse täielikult enne järgmise algust; koskmudeli atraktiivsus avalikele organitele on alati olnud see, et selle vahe-eesmärgid kaardistuvad puhtalt fikseeritud hinnaga lepingule ja iga-aastasele eelarvetsüklile, mistõttu nii paljud hankeõigused eeldavad seda endiselt, isegi kus tarne on tõeliselt agiilne.

Minimaalselt elujõuline toode on teenuse väikseim versioon, mille saab päris kasutajatele välja lasta, et testida, kas see töötab, ja õppida, mida järgmisena ehitada. Minimaalselt elujõulise toote kontseptsioon, kohandatuna avaliku sektori digitaalteenuste käsiraamatutesse, annab iteratiivsele meeskonnale kaitstava viisi näidata rahastajale või audiitorile midagi tõelist ja töötavat kaua enne täieliku ulatuse valmimist – tingimusel, et vastutusprotsess aktsepteerib tõeliselt minimaalset väljalaset, mitte ei käsitle seda valmis tootena teise nime all.

Parimad tavad

1. Ostke vaikimisi eristamatute vajaduste jaoks ja reserveerige ehitamine sellele, mis on tõeliselt eristuv. Palgaarvestus, e-post ja üldised juhtumikorralduse vajadused erinevad harva piisavalt ükskõik millise teise organisatsiooni omadest, et õigustada eritarkvara; ehitage ainult seal, kus nõue, mastaap või vajadus suutlikkust aastakümneid omada ja arendada on tõeliselt erinev sellest, mida turg pakub.
2. Tehke tehniline võlg nähtavaks enne otsustamist, kui palju seda kanda. Hoidke iga kasutusel oleva süsteemi teadaolevate otseteede, edasilükatud paranduste ja toetamata sõltuvuste registrit, mida vaadatakse üle kindla tsükli järgi, nii et võla kandmine veel üheks aastaks on tahtlik kompromiss, mitte see, et keegi ei vaadanud.
3. Ärge kunagi planeerige ühte, pöördumatut üleminekut kui ainsat teed kriitilisest pärandsüsteemist välja. Eelistage järkjärgulisi lähenemisi, nagu kägistajaviigipuu muster, mis laseb iga tüki testida, tagasi pöörata ja järk-järgult välja viia; süsteemi, millest miljonid sõltuvad, suurpauk-asendus koondab aastate riski ühele nädalavahetusele, ilma teed tagasi, kui midagi ebaõnnestub.
4. Käsitlege lähtekoodi, mille kirjutamise eest teie organisatsioon maksab, varana, mida ta omab, mitte teenusena, mida ta rendib. Läbirääkige lähtekoodi hoiustamise (escrow) või täieliku omandi üle lepingu sõlmimise hetkel, mitte pärast vaidluse algust, kuna tarnija, kes hoiab ainsat koopiat teie kriitilise teenuse koodist, on tarnijasõltuvus kavandi järgi.
5. Avaldage lähtekood vaikimisi avatuna ja nõudke konkreetset põhjendust selle tagasihoidmiseks. Järjepidevalt rakendatud avatud lähtekoodi vaikimisi poliitika muudab iga osakonna kohandatud tarkvara jagatud valitsusülese varaks, mitte ühekordseks kuluks, ja laseb välistel ekspertidel leida turvavigu, mida sisemine meeskond üksi märkamata jätaks.
6. Kirjutage tarkvaralepingud nii, et iteratiivne tarne on õiguslikult lubatud, mitte ainult tehniliselt võimalik. Leping, mis maksab ainult allkirjastamisel kokku lepitud fikseeritud spetsifikatsiooni vastu, sunnib meeskonda valima ausa agiilse praktika ja lepingulise vastavuse vahel; kasutage selle asemel etapiviisilisi rahastamisväravaid, mis on seotud demonstreeritud töötava tarkvaraga, mitte üht vahe-eesmärki lõpus.
7. Rahastage moderniseerimist pideva programmina, mitte ühekordse kapitaliprojektina. Pärandsüsteem, mis moderniseeritakse üks kord ja jäetakse siis veel kahekümneks aastaks, kogub sama riski, millega see algas; eelarvestage pidevat, järkjärgulist uuendamist nii, nagu teedeamet eelarvestab uuesti asfalteerimist, mitte suurt asendust kord põlvkonnas.
8. Valige avatud standardid ja teisaldatavad andmevormingud isegi kaubandusliku tarkvara ostmisel. Nõudmine, et tarnija süsteem salvestaks ja eksportiks andmeid avatud, dokumenteeritud vormingutes, hoiab ülemineku kulud madalad isegi kus tarkvara ise on patenteeritud, ja on sageli saavutatavam lähiajaline kaitsemeede sõltuvuse vastu kui nõudmine, et iga süsteem oleks avatud lähtekoodiga.
9. Ehitage minimaalselt elujõuline toode ja näidake seda päris kasutajatele enne täieliku ulatuse kohustumist. Tõeliselt minimaalse versiooni väljalaskmine, seejärel õpitu põhjal iteratsioon, tabab valed eeldused, kuni neid on veel odav parandada, mitte pärast seda, kui nende vastu on ehitatud täismahus süsteem.
10. Hoidke piisavat sisemist inseneri suutlikkust, et olla arukas ostja, isegi kus tarne on allhangitud. Avalik organ, kes on oma tehnilise ekspertiisi õõnestanud, ei suuda hinnata tarnija ettepanekut, märgata raskustes projekti varajasi hoiatusmärke ega pidada läbirääkimisi sõltuvusest välja pääsemiseks, olenemata sellest, mida tema hankereeglid paberil ütlevad.
11. Kõrvaldage pärandsüsteemi riskid enne selle kasutajaliidese uuendamist. Prioriseerige toetamata keelte, parandamata taristu ja dokumenteerimata integratsioonide asendamist – ebaõnnestumised, mis põhjustavad seisakuid ja rikkumisi – enne visuaalset moderniseerimist, mis kannab palju väiksemat operatiivset riski.
12. Mõõtke tarne tervist inseneriindikaatoritega, mitte ainult eelarve- ja ajakavaerinevusega. Kasutuselevõtu sagedus, defektide määrad ja vanima lahendamata tehnilise võla kirje vanus ütlevad juhtorganile rohkem selle kohta, kas programm õnnestub, kui see, kas see on praegu eelarve piires, mis on sageli viimane indikaator, mis liigub.

Küsimused arutamiseks oma meeskonnaga

Kas me tegelikult teame, kui palju tehnilist võlga me süsteemide kaupa kanname? Enamik avalikke organeid suudab nimetada oma aasta kapitalieelarve, kuid ei suuda öelda, kui kindlalt, kui suur osa nende tarkvarapargist töötab toetamata komponentidel, dokumenteerimata loogikal või koodil, mida keegi allesjäänud töötajatest täielikult ei mõista. Kasutage seda küsimust, et paluda igal ruumis oleval süsteemi omanikul ausalt hinnata, kui kindel ta on, et tema meeskond saaks oma kõige kriitilisema süsteemi ohutult muuta, midagi ootamatut rikkumata. Arutage, mida oleks vaja nende hinnangute muutmiseks tegelikuks registriks, mida vaadatakse üle kindla tsükli järgi, mitte hõimuteadmiseks, mis lahkub, kui võtmeinsener lahkub. Kaaluge ka, kes praegu otsustab, kui palju võlga on vastuvõetav kanda, ja kas see otsus on tahtlik või vaikimisi.

Kui meie kõige kriitilisem pärandsüsteem tuleks asendada alates tänasest, kas me planeeriksime suurpauk-ülemineku või järkjärgulise migratsiooni – ja miks? Instinkt asendada vana süsteem korraga on sageli ajendatud eelarvetsüklitest ja programmijuhtimise mugavusest, mitte tehnilisest vajadusest, ja see koondab tohutu riski ühele hetkele. Kasutage seda küsimust, et käia läbi, konkreetselt, milline näeks tegelikult välja teie kõige kriitilisema pärandsüsteemi kägistajaviigipuu stiilis järkjärguline migratsioon, tükk tüki haaval. Arutage, mis takistab teid täna seda teed valimast – rahastus, mis on struktureeritud ühe käivituskuupäeva ümber, juhtimisprotsess, mis tahab ühte puhast vahe-eesmärki, või tõeline tehniline piirang, mis muudab järkjärgulise migratsiooni selle süsteemi jaoks võimatuks.

Kes tegelikult omab lähtekoodi tarkvara jaoks, mille ehitamise eest meie organisatsioon on maksnud, ja kas me suudaksime seda tõestada? Paljud avalikud organid avastavad alles siis, kui suhe tarnijaga hapuks läheb, et leping ei taganud kunagi selget omandit ega hoiustamist koodi üle, millest nende kriitilised teenused sõltuvad. Kasutage seda küsimust, et tuua välja oma kolme kõige olulisema eritarkvarasüsteemi lepingud ja kontrollida konkreetselt, mida iga ütleb koodi omandi, hoiustamise ja õiguse kohta koodi teise tarnijani viia. Arutage, mis juhtuks homme, kui teie esmane tarnija mis tahes neist kolmest süsteemist läheks pankrotti või keelduks suhet jätkamast.

Kus me vaikimisi kasutame suletud, patenteeritud tarkvara harjumusest, kui avatud lähtekoodi vaikimisi lähenemine teeniks meid sama hästi või paremini? Avatud lähtekoodi vaikimisi poliitikad on olemas just seetõttu, et enamik avalikke organeid lahendab kattuvaid probleeme sõltumatult, iga maksab täishinda tarkvara eest, mille teine avalik organ on juba ehitanud ja oleks saanud jagada. Kasutage seda küsimust, et tuvastada üks süsteem, mida praegu ehitatakse või täpsustatakse, ja küsida, kas samaväärne eksisteerib juba avatud lähtekoodiga tarkvarana mujal valitsuses või kas see, mida te ehitate, võiks kasulikult välja anda teiste taaskasutuseks. Arutage, milline konkreetne tõke – turvaprobleem, hankeharjumus, selge poliitika puudumine – tegelikult selle taaskasutuse takistab, selle asemel et eeldada, et see siin ei ole asjakohane.

Kas meie hanke- ja vastutusprotsess lubab tegelikult ausat agiilset tarnet või ainult nimetab koskmudeli vahe-eesmärke sprintideks? On tavaline, et meeskond viib läbi nominaalselt agiilseid tseremooniaid, samal ajal kui teda ikkagi rahastatakse, juhitakse ja aruandlusega kaetakse lepingu allkirjastamisel kokku lepitud fikseeritud spetsifikatsiooni vastu, mis taastoodab iga koskmudeli ebaõnnestumisviisi agiilse sildi all. Kasutage seda küsimust, et jälgida üht elavat digiprogrammi selle ärijuhtumist kuni praeguse juhtimisaruandluseni ja küsida, kas rahastusstruktuur talub programmi suuna muutmist selle põhjal, mida tõeline varane väljalase seda õpetas. Arutage, mida oleks vaja muuta programmi rahastamises ja aruandluses, et iteratiivne tarne oleks tõeline, mitte kosmeetiline (vt Teema 3.7 — Riigihanked ja tellimine).

Kas meil on piisavalt sisemist inseneri suutlikkust, et olla arukas ostja süsteemidele, millest me kõige enam sõltume? Organisatsioon, mis on allhanginud kogu oma tehnilise otsustusvõime, mitte ainult tarnevõime, ei suuda öelda, kas tarnija ettepanek on terve, kas projekt liigub vaikselt probleemide poole või mis on töö õiglane hind. Kasutage seda küsimust, et küsida, kui paljud teie organisatsioonis saaksid usutavalt üle vaadata tehnilise arhitektuuri ettepaneku teie kõige olulisema süsteemi jaoks ja kuidas see arv on viimase viie aasta jooksul muutunud. Arutage, mida oleks vaja selle suutlikkuse taastamiseks seal, kus see on erodeerunud, ja mida teie organisatsioon kaotab, läbirääkimispositsioonis sama palju kui tarneriskis, iga aasta eest, mil see ilma jääb.

Praktikas: avaliku väärtuse näide

Väljamõeldud piirkondlik valitsus – ainult illustratiivne, mitte ühegi tegeliku jurisdiktsiooni kirjeldus – käitas oma töötutoetuse nõudeid süsteemi kaudu, mis oli esmakordselt kirjutatud üle kolmkümmend aastat tagasi ja mida hooldas kahanev arv inimesi, kes mõistsid selle algset programmeerimiskeelt. Nõuete maht oli kasvanud kaugelt üle selle, mida süsteemi kavandajad olid ette näinud, öised töötlusjooksud ei lõppenud üha sagedamini enne hommikuste tehingute algust ning ameti tehnoloogiajuhtkond hoiatas, et toetusmaksetele mõjuv plaaniväline seisak on nüüd küsimus mitte kas, vaid millal.

Ameti esimene instinkt oli tavapärane vastus probleemile, mis tundus pakiline: tellida üks suur leping kogu süsteemi asendamiseks kaasaegse platvormiga, täielikult ette täpsustatud, tarnitud fikseeritud kaheaastase ajakava järgi ühe üleminekunädalavahetusega lõpus. Ameti auditikomitee tellitud eelrakendusülevaatus tõstatas enne lepingu allkirjastamist raske küsimuse: mis juhtuks mitusada tuhat taotleja toetusmaksetega, kui uues süsteemis oleks avastamata defekt oma täismahus elava töö esimesel nädalal, kui vana süsteem on juba maha võetud ja teed tagasi pole.

Amet muutis kurssi. See hoidis pärandsüsteemi töös kirjete süsteemina ja hakkas selle kõrval ehitama uut nõuete vastuvõtmise ja kõlblikkuse hindamise funktsionaalsust, kasutades kägistajaviigipuu lähenemist: iga uus moodul lasti esmalt välja väikesele protsendile uutest nõuetest, kontrolliti vana süsteemi paralleelse väljundi vastu ja laiendati alles siis, kui selle tulemused ühtisid. Kaheksateist kuud hiljem jooksis enamik uusi nõudeid läbi kaasaegsete komponentide, samal ajal kui algne süsteem käsitles kahanevat jääkjuhtumite koormust, võimega suunata mis tahes üksik juhtum vanale teele tagasi, kui miski paistis vale. Amet nõudis ka igas selle töö jaoks väljastatud uues lepingus, et lähtekood kuuluks ametile ja avaldataks avatud lähtekoodina, kui turvaülevaatus on lõpetatud, nii et teised piirkondlikud valitsused, kes seisid silmitsi sama vananeva suurarvuti probleemiga, saaksid komponente kohandada, mitte kordama sama ehitust nullist.

Pärandsüsteemi viimaste jääkfunktsioonide täielik asendamine võttis ligi neli aastat – paberil kauem, kui algne suurpauk-plaan kaheks aastaks lubas. Kuid ükski taotleja ei kogenud üleminekul kunagi plaanivälist seisakut, iga juurdekasv oli piisavalt väike, et see saaks tundide jooksul tagasi pöörata, kui defekt leiti, ja kaks naaberpiirkondlikku valitsust hakkasid ameti avaldatud kõlblikkuse hindamise koodi oma süsteemide jaoks kohandama oma esimese väljalaskeaasta jooksul.

Neli sektoriläätse

Kohalik omavalitsus

Kohalik omavalitsus käitab tavaliselt suurt hulka väiksemaid, ühendamata süsteeme, mitte käputäit riigi mastaabis platvorme, mis tähendab, et tehniline võlg kuhjub paljudes eraldi hangitud, eraldi hooldatud rakendustes, mitte ühes nähtavas lipulaevasüsteemis. Kohalikel omavalitsustel on tavaliselt valitsuse tasanditest kõige vähem sisemist inseneri suutlikkust, mis teeb juhtumi seadistatava kaubatarkvara ostmiseks eritarkvara ehitamise asemel eriti tugevaks ning teeb jagatud piirkondlikud või riiklikud platvormid – teema 5.1 aine (vt Teema 5.1 — Digitaalne valitsemine ja digitaalne ümberkujundamine) – eriti kõrge väärtusega teeks vältida, et iga omavalitsus ehitaks eraldi sama suutlikkust uuesti.

Riigivalitsus

Riigivalitsus on koht, kus kipuvad asuma vanimad ja kõige tagajärjekamad pärandsüsteemid – põhilised maksu-, sotsiaalkindlustuse ja toetuste haldus –, sest need olid sageli valitsuse esimeste suuremahuliste arvutistamispüüdluste hulgas ja kannavad nüüd kõrgeimaid panuseid mis tahes moderniseerimise ebaõnnestumisel. Riigivalitsusel on tavaliselt spetsialiseeritud kaubanduslik ja inseneri suutlikkus tõeliselt järkjärgulise moderniseerimisprogrammi läbiviimiseks ja tõelise koodi omandi lepingutesse läbirääkimiseks ning see on tavaliselt valitsustasand, mis on kõige paremas seisus seadma avatud lähtekoodi vaikimisi poliitikat piisava mastaabiga selle taga, et valitsusülene taaskasutus tegelikult juhtuks.

Sotsiaalsektor ja mittetulundussektor

Mittetulundusühingud ja heategevusorganisatsioonid harva ehitavad ise suuri eriplatvorme, kuid on sageli vastuvõtvas otsas tarkvarale, mille on tellinud või kohustuslikuks teinud valitsuse rahastaja – aruandlusportaal, juhtumikorralduse süsteem, mida toetus või leping nõuab nende kasutamist –, vähese mõjuga selle kavandile, tehnilisele võlale või tarnijale. Sotsiaalsektori organisatsioon, mis sõltub valitsuse kohustuslikust süsteemist, pärib selle süsteemi ebaõnnestumisviisid, ilma ühegi hoovata nende parandamiseks, mis on veel üks põhjus, miks tulemuspõhised rahastussuhted peavad arvestama kohustusliku tehnoloogia operatiivse koormusega (vt Teema 3.7 — Riigihanked ja tellimine), mitte ainult tulemusmõõdikuga ise.

Mitmepoolne ja rahvusvaheline

Mitmepoolsed organid ja arenguasutused propageerivad üha enam ühe riigi avaliku halduse jaoks ehitatud tarkvara taaskasutatava digitaalse avaliku hüvena, mida teised riigid saavad kohandada, mitte et iga valitsus tellib samaväärse süsteemi erasektori tarnijalt täishinnaga. Siinne eriline risk on see, et ühe riigi õigus- ja haldusliku konteksti jaoks ehitatud digitaalne avalik hüve võidakse mujal omaks võtta liiga vähese kohandamisega, importides eeldusi – identiteedi, kõlblikkuse või protsessi kohta –, mis tegelikult ei kandu üle; jagatud, avatud taristu lubadus on tõeline, kuid ainult kus koodiga käib kaasas tõeline kohalik kohanemissuutlikkus.

Levinud ebaõnnestumisviisid

Suurpauk-üleminek, mis ebaõnnestub käivitamisel. Kriitiline pärandsüsteem asendatakse ühe, pöördumatu üleminekuga pärast aastatepikkust arendust ilma elava tootmiskokkupuuteta ning defekt, mis ilmneb ainult tegelikus mastaabis või äärejuhtumis, mida keegi ei testinud, ilmneb täieliku töö esimesel päeval, ilma võimaluseta vana süsteemi juurde tagasi pöörduda, sest see on juba maha võetud. Kulu mõõdetakse jäänud maksetes, keeldutud teenustes või seisakutes, mis mõjutavad täpselt kodanikke, keda süsteem teenindab, kõige halvemal võimalikul hetkel – hetkel, mil kõik lootsid, et asendus töötab.

Vaikne tehnilise võla kuhjumine. Tähtaja surve võidab korduvalt vaidluse selle üle, kas kulutada aega teadaolevate otseteede parandamisele, ja iga edasilükkamine on eraldi kaitstav, kuni kuhjunud võlg muudab isegi väikese muudatuse ebaproportsionaalselt kalliks ja riskantseks. Kulu ilmneb aastaid hiljem süsteemina, mida keegi ei saa ohutult muuta, tööjõuna, mis on vaikselt lõpetanud kõigi muu kui kõige pakilisemate paikade proovimise, ja lõpuks moderniseerimisprogrammina, mis on palju suurem ja kallim, kui pidev, väiksem uuendamine oleks olnud.

Tarnijasõltuvus, mida peetakse stabiilsuseks. Avalik organ pikendab sama tarnija lepingut korduvalt, sest üleminek tundub liiga häiriv proovimiseks, kunagi testimata, mis tegelikud ülemineku kulud oleksid, ega pidamata läbirääkimisi koodi omandi ja avatud andmevormingute üle, mis hoiaksid need kulud hallatavad. Kulu on püsivalt nõrgenenud läbirääkimispositsioon hinna ja tingimuste osas, mis avastatakse alles siis, kui tarnija teenuse kvaliteet langeb või hind tõuseb ja avalik organ leiab, et tal pole usaldusväärset alternatiivi.

Kosmeetiline agiilsus. Tarnemeeskond võtab omaks agiilsed tseremooniad – päevakoosolekud, sprindid, mahajäämus –, samal ajal kui aluseks olev leping, rahastus ja juhtimisstruktuur eeldavad endiselt fikseeritud spetsifikatsiooni ja ühte go/no-go vahe-eesmärki, nii et meeskond aruandleb sprindi kiirusest, tarnides tegelikult koskmudeli plaani alusel. Kulu on see, et ükski agiilsuse tõeline kasu – varane kasutajate tagasiside, mis suunda muudab, varakult esile toodud risk – ei realiseeru, samal ajal kui kaasaegse praktika välimus muudab aluseks oleva jäikuse järelevalveorganitele raskemini nähtavaks ja vaidlustatavaks.

Avatud lähtekoodi poliitika ilma jätkusuutlikkuse plaanita. Avalik organ avaldab lähtekoodi avatud lähtekoodi vaikimisi poliitika rahuldamiseks, kuid käsitleb väljalaset ühekordse vastavussammuna, ilma ressurssideta väliste panuste ülevaatamiseks, haavatavuste parandamiseks või dokumentatsiooni hooldamiseks. Kulu on avaldatud hoidla, mis paistab avatuna, kuid toimib hooldamata ummikteena, mis kahjustab usaldust laiema avatud lähtekoodi vaikimisi programmi vastu rohkem, kui avaldamata jätmine oleks teinud.

Küpsusmudel

Kontrollnimekiri

• Inventeerige iga kriitilise süsteemi tehniline võlg ja vaadake registrit üle kindla tsükli järgi.
• Rakendage dokumenteeritud ehita-versus-osta raamistikku enne mis tahes olulise uue tarkvara kohustumist.
• Mis tahes pärandsüsteemi asendamise puhul valige vaikimisi järkjärguline migratsioonimeetod ja nõudke selgesõnalist põhjendust suurpauk-ülemineku jaoks.
• Kinnitage lähtekoodi omandi või hoiustamise tingimused igas tarkvaralepingus enne allkirjastamist.
• Avaldage lähtekood avatud lähtekoodi vaikimisi poliitika alusel, dokumenteeritud erandiprotsessiga.
• Ressursseerige pidev hooldus iga selle poliitika alusel avaldatud hoidla jaoks, mitte ainult selle esialgne väljalase.
• Nõudke avatud, dokumenteeritud andmevorminguid isegi kus aluseks olev tarkvara on patenteeritud.
• Struktureerige rahastusvärav demonstreeritud töötava tarkvara, mitte ühe fikseeritud spetsifikatsiooni vahe-eesmärgi ümber.
• Ehitage ja testige minimaalselt elujõuline toode päris kasutajatega enne täieliku ulatuse kohustumist.
• Jälgige kasutuselevõtu sagedust, defektide määrasid ja lahendamata tehnilist võlga püsivate juhtimisindikaatoritena.
• Hinnake sisemist inseneri suutlikkust selle vastu, mida on vaja arukaks ostjaks olemiseks, ja sulgege tuvastatud lüngad.
• Prioriseerige toetamata taristu ja dokumenteerimata integratsioonid kosmeetilise moderniseerimise ees.

Põhiallikad

• GOV.UK Service Standard, Government Digital Service, Ühendkuningriik – riiklik digitaalteenuse standard, mis nõuab iteratiivset, kasutajakeskset tarnet ja avatud standardeid avalike teenuste jaoks.
• Office of Management and Budget, Federal Source Code Policy (M-16-21), Ameerika Ühendriigid – föderaalne poliitika, mis nõuab asutustelt taaskasutuse ja avatud lähtekoodi väljalaske kaalumist kohandatud valitsuse tarkvara jaoks.
• Free Software Foundation Europe, Public Money, Public Code kampaania – põhjendus, välja töötatud Euroopa auditooriumile, avaliku rahaga rahastatud tarkvara lähtekoodi väljalaskmiseks vabade ja avatud lähtekoodiga litsentside alusel.
• Ward Cunningham, „The WyCash Portfolio Management System" (OOPSLA 1992 kogemusaruanne) – tehnilise võla metafoori algne väide.
• Digital Public Goods Alliance – mitme sidusrühmaga algatus, mis hooldab standardeid ja registrit avatud tarkvara, andmete ja sisu jaoks, mis on kavandatud avalikke arengueesmärke teenima.

Viited

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/