Aihe 5.3 — Julkisen sektorin ohjelmistotuotanto ja alustat

Miksi tällä on merkitystä julkisen arvon kannalta

Lähes jokainen julkinen palvelu, jonka kanssa kansalainen nykyisin asioi — syntymän rekisteröinti, etuuden hakeminen, veron maksaminen, oikeudenkäyntiajan varaaminen — toimii jonkin ohjelmiston varassa luukun tai ruudun takana. Tuo ohjelmisto on harvoin kertaluonteinen hankinta; siitä tulee osa valtion pysyvää infrastruktuuria, joka usein elää pidempään kuin sen tilannut hallinto, sen rakentanut toimittaja ja ohjelmointikieli, jonka insinöörit olivat oppineet. Julkinen elin ei koe ohjelmistoa samalla tavalla kuin rakennusta tai tietä, joiden omaisuuserän kunto on näkyvä; ohjelmisto rapautuu näkymättömästi, ja laskun rapautumisesta saa vuosia myöhemmin hätätilanteena.

Tämän aiheen taustalla oleva jännite on rakenteellinen. Ohjelmisto on luonteeltaan iteratiivista — vaatimukset tarkentuvat, kun käyttäjät ovat vuorovaikutuksessa toimivan järjestelmän kanssa, ja paras insinöörikäytäntö on rakentaa jotain pientä, oppia ja mukautua. Julkiset hankinta- ja vastuullisuussyklit (katso Aihe 3.7 — Julkiset hankinnat ja tilaaminen) sitä vastoin rakennettiin pääomatöitä ja puolustussopimuksia varten: kiinteä määrittely, yksi suuri myöntö, virstanpylväsmaksut ja hankeperustelu, joka on hyväksytty vuosia ennen kuin toimitus alkaa. Kun lainsäätäjä tai tarkastaja odottaa kiinteähintaista, kiinteän laajuuden sopimusta ja insinööritiimin on muutettava suuntaa ensimmäisen julkaisun jälkeen, epäsuhta näkyy laajuuden hiipimisenä, budjetin ylityksenä tai järjestelmänä, joka määriteltiin oikein vuonna 2019 ja oli vanhentunut siihen mennessä, kun se otettiin käyttöön.

Alustat, jotka tämän aiheen insinöörikäytäntö on olemassa rakentamaan — jaetut tunnistamisjärjestelmät, maksuväylät, osastojen yli uudelleenkäytetyt tapausten hallintatyökalut — ovat Aiheen 5.1 aihe (katso Aihe 5.1 — Digitaalinen hallinto ja digitaalinen muutos); tämä aihe käsittelee sellaisen ohjelmiston rakentamisen ja ostamisen kuria, joka tekee mistä tahansa tällaisesta alustasta tai mistä tahansa yksittäisestä palvelusta luotettavan, vaihdettavan ja sen julkisen elimen omistaman, joka siitä riippuu, eikä sen toimittajan, joka sattui kirjoittamaan sen ensimmäisenä.

Keskeiset käsitteet

Rakenna vai osta -päätös on valinta sellaisen räätälöidyn ohjelmiston tilaamisen välillä, joka on kirjoitettu yhden organisaation tarpeeseen, ja jo valmiiksi samankaltaisten ostajien markkinaa varten rakennetun konfiguroitavan hyödykeohjelmiston käyttöönoton välillä. Ostaminen on yleensä halvempaa ja pienempiriskistä tarpeelle, joka ei ole aidosti omaleimainen — palkanlaskenta, sähköposti, tavallinen tapausten hallinta —, kun taas rakentaminen on perusteltua vain siellä, missä vaatimus on niin erilainen, ettei mikään konfiguroitava tuote sovi, tai missä kyvykkyys on itsessään strateginen omaisuus, jonka organisaation on omistettava ja kehitettävä.

Tekninen velka on ohjelmistoinsinööri Ward Cunninghamin vuonna 1992 lanseeraama vertauskuva sille kertyneelle kustannukselle, joka syntyy, kun valitaan tarkoituksenmukainen tapa toimittaa ohjelmisto nyt perusteellisemman tavan sijaan, joka olisi vienyt kauemmin. Tekninen velka ei ole rahoitusvelan tavoin luonnostaan väärin otettavaksi — Cunninghamin oma pointti oli, että toimivan koodin nopea toimittaminen ja uudelleenjärjestely jälkikäteen voi olla oikea ratkaisu —, mutta velka, jota ei koskaan makseta takaisin, kerryttää korkoa hitaampana toimituksena, enemmän vikoina ja kasvavana riskinä, ja julkinen elin, joka ei näe velkaansa, ei voi päättää, hoitaako se sitä vai antaako sen kasvaa korkoa korolle.

Perintöjärjestelmä (legacy system) on vanha teknologia, sovellus tai alusta, joka pysyy aktiivisessa käytössä vanhentuneesta huolimatta, usein koska sen korvaaminen on kallista tai koska kukaan organisaatioon jääneistä ei täysin ymmärrä, mitä se tekee. Perintöjärjestelmät ovat erityisen sitkeitä hallinnossa: vuosikymmeniä sitten kirjoitetut keskeiset vero-, etuus- ja sosiaalivakuutusjärjestelmät kielillä kuten COBOL — Common Business-Oriented Language, suunniteltu vuonna 1960 hallinnolliseen tietojenkäsittelyyn — käsittelevät yhä tapahtumia miljoonille kansalaisille, koska järjestelmät toimivat ja institutionaalinen tieto, jota tarvitaan niiden turvalliseen lakkauttamiseen, on usein jäänyt itse eläkkeelle ensin.

Ohjelmiston nykyaikaistaminen on yleistermi perintöjärjestelmän muuntamiselle, uudelleenkirjoittamiselle tai siirtämiselle nykyiselle arkkitehtuurille, kielelle tai alustalle. Ohjelmiston nykyaikaistaminen ulottuu jatkumolle täydellisestä uudelleenkirjoituksesta konservatiivisempiin vaihtoehtoihin kuten saman koodin siirtämiseen nykyaikaiselle infrastruktuurille, ja valinta niiden välillä on yhtä paljon riskienhallintapäätös kuin tekninen.

Kuristajaviikuna-malli (strangler fig pattern) on vaiheittainen nykyaikaistamistapa, nimetty puuta ympäröivän ja vähitellen sen korvaavan köynnöksen mukaan, jossa uutta toiminnallisuutta rakennetaan perintöjärjestelmän rinnalle ja liikenne ohjataan siihen pala palalta koko järjestelmän korvaamisen sijaan yhdellä siirtymällä. Kuristajaviikuna-malli on tärkeä, koska se antaa jokaisen lisäyksen testata, peruuttaa tai keskeyttää viemättä koko palvelua alas — päinvastoin kuin kertasiirtymä, jossa vanha järjestelmä sammutetaan ja uusi käynnistetään yhdellä hetkellä ilman paluumahdollisuutta, jos jokin on pielessä.

Toimittajalukko (vendor lock-in) syntyy, kun asiakas tulee niin riippuvaiseksi yhden toimittajan omistusoikeudellisesta teknologiasta, tietomuodoista tai sopimusehdoista, että toiseen toimittajaan vaihtaminen kantaa kohtuuttoman kustannuksen tai riskin. Toimittajalukko on erityinen vaara julkisen sektorin ohjelmistoissa, koska ostaja on toistuva asiakas, jolla on rajallinen käytännön kyky kävellä pois kriittistä palvelua pyörittävästä järjestelmästä, mikä heikentää sen neuvotteluasemaa jokaisella myöhemmällä uusimiskerralla.

Vapaa ja avoimen lähdekoodin ohjelmisto on ohjelmisto, jota jaetaan lisenssillä, joka antaa käyttäjille vapauden käyttää, tutkia, muokata ja levittää uudelleen lähdekoodia. Vapaa ja avoimen lähdekoodin ohjelmisto on avoin oletuksena -politiikan perusta, jonka mukaan julkinen elin julkaisee tilaamansa lähdekoodin oletuksena, ellei erityinen syy — turvallisuusherkkyys, kolmansien osapuolten oikeudet — oikeuta pidättämään sitä; perustelu tiivistetään yleensä muotoon ”julkinen raha, julkinen koodi”: kerran julkisilla varoilla maksettua ohjelmistoa ei pitäisi tarvita maksaa uudelleen, toisessa lainkäyttöalueessa, toisen julkisen elimen toimesta, joka ratkaisee saman ongelman.

Digitaalinen julkishyödyke on avoin ohjelmisto, data tai sisältö, joka on julkaistu avoimella lisenssillä ja suunniteltu auttamaan täyttämään julkinen kehitys- tai hallintotavoite kaupallisen tuoton tuottamisen sijaan. Digitaaliset julkishyödykkeet kehystävät yhden hallituksen avoimen lähdekoodin julkaisun osaksi laajempaa, jaettua infrastruktuuria, jota muut hallitukset ja kansalaisyhteiskunnan organisaatiot voivat hyödyntää suoraan, ei vain sisäisenä avoimuuden eleenä.

Ketterä ohjelmistokehitys (agile) on kattotermi iteratiivisille tavoille rakentaa ohjelmistoa, jotka suosivat toimivaa ohjelmistoa, tiheää toimitusta ja muutokseen vastaamista etukäteen sovitun kiinteän suunnitelman noudattamisen sijaan. Ketterä ohjelmistokehitys on vastakohta vesiputousmallille, peräkkäiselle lähestymistavalle, jossa vaatimukset, suunnittelu, rakentaminen ja testaus valmistuvat kukin täysin ennen seuraavan alkamista; vesiputouksen vetovoima julkisille elimille on aina ollut, että sen virstanpylväät vastaavat siististi kiinteähintaista sopimusta ja vuosittaista budjettisykliä, minkä vuoksi niin suuri osa hankintalaista olettaa sen edelleen, vaikka toimitus olisi aidosti ketterää.

Minimaalinen elinkelpoinen tuote (minimum viable product) on pienin versio palvelusta, joka voidaan julkaista oikeille käyttäjille testaamaan, toimiiko se, ja oppimaan, mitä rakentaa seuraavaksi. Minimaalisen elinkelpoisen tuotteen käsite, mukautettuna julkisen sektorin digitaalisten palvelujen pelikirjoihin, antaa iteratiiviselle tiimille puolustettavan tavan näyttää rahoittajalle tai tarkastajalle jotain todellista ja toimivaa kauan ennen täyden laajuuden valmistumista — edellyttäen että vastuullisuusprosessi hyväksyy aidosti minimaalisen julkaisun sen sijaan että käsittelisi sitä valmiina tuotteena toisella nimellä.

Parhaat käytännöt

Osta oletuksena erottumattomiin tarpeisiin ja varaa rakentaminen sille, mikä on aidosti omaleimaista. Palkanlaskenta, sähköposti ja yleiset tapausten hallinnan tarpeet ovat harvoin tarpeeksi erilaisia kuin minkä tahansa muun organisaation oikeuttaakseen räätälöidyn ohjelmiston; rakenna vain missä vaatimus, mittakaava tai tarve omistaa ja kehittää kyvykkyyttä vuosikymmenten ajan on aidosti erilainen kuin mitä markkina tarjoaa.
Tee tekninen velka näkyväksi ennen kuin päätät, kuinka paljon sitä kannat. Ylläpidä jokaiselle käytössä olevalle järjestelmälle rekisteriä tunnetuista oikopoluista, lykätyistä korjauksista ja tukemattomista riippuvuuksista, tarkistettuna kiinteällä syklillä, jotta velan kantaminen vielä vuoden on tietoinen kompromissi eikä sitä, ettei kukaan katsonut.
Älä koskaan suunnittele yhtä, peruuttamatonta siirtymää ainoaksi reitiksi pois kriittisestä perintöjärjestelmästä. Suosi vaiheittaisia lähestymistapoja kuten kuristajaviikuna-malli, jotka antavat jokaisen osan testata, peruuttaa ja ottaa käyttöön vähitellen; järjestelmän, josta miljoonat riippuvat, kertasiirtymä keskittää vuosien riskin yhteen viikonloppuun ilman paluumahdollisuutta, jos jokin epäonnistuu.
Käsittele lähdekoodia, jonka kirjoittamisesta organisaatiosi maksaa, omistamanaan omaisuutena eikä vuokraamanaan palveluna. Neuvottele lähdekoodin escrow tai suora omistus sopimuksentekohetkellä, ei kiistan alettua, koska toimittaja, jolla on ainoa kopio kriittisen palvelusi koodista, on toimittajalukko suunnittelun kautta.
Julkaise lähdekoodi avoimena oletuksena ja vaadi erityinen perustelu sen pidättämiseen. Johdonmukaisesti sovellettu avoin oletuksena -politiikka muuttaa jokaisen osaston räätälöidyn ohjelmiston jaetuksi hallinnon laajuiseksi omaisuudeksi kertakustannuksen sijaan ja antaa ulkopuolisten asiantuntijoiden löytää tietoturva-aukkoja, jotka sisäinen tiimi yksin ohittaisi.
Kirjoita ohjelmistosopimukset niin, että iteratiivinen toimitus on laillista, ei vain teknisesti mahdollista. Sopimus, joka maksaa vain allekirjoituksessa sovittua kiinteää määrittelyä vastaan, pakottaa tiimin valitsemaan rehellisen ketterän käytännön ja sopimuksenmukaisuuden välillä; käytä sen sijaan vaiheittaisia rahoitusportteja, jotka on sidottu osoitettuun toimivaan ohjelmistoon yhden virstanpylvään sijaan lopussa.
Rahoita nykyaikaistaminen jatkuvana ohjelmana, ei kertaluonteisena pääomahankkeena. Kerran nykyaikaistettu ja sitten kahdeksikymmeneksi vuodeksi jätetty perintöjärjestelmä kerää saman riskin, jolla se alkoi; budjetoi jatkuvaan, vaiheittaiseen uudistamiseen samalla tavalla kuin tieviranomainen budjetoi uudelleenpäällystykseen, ei suureen korvaamiseen kerran sukupolvessa.
Valitse avoimet standardit ja siirrettävät tietomuodot myös kaupallista ohjelmistoa ostaessa. Sen vaatiminen, että toimittajan järjestelmä tallentaa ja vie dataa avoimissa, dokumentoiduissa muodoissa, pitää vaihtokustannukset matalina silloinkin, kun ohjelmisto itse on omistusoikeudellista, ja on usein saavutettavissa oleva lyhyen aikavälin suoja toimittajalukkoa vastaan kuin sen vaatiminen, että jokainen järjestelmä on avointa lähdekoodia.
Rakenna minimaalinen elinkelpoinen tuote ja näytä se oikeille käyttäjille ennen täyteen laajuuteen sitoutumista. Aidosti minimaalisen version julkaiseminen ja sitten opitun pohjalta iterointi saa väärät oletukset kiinni silloin, kun ne ovat vielä halpoja korjata, sen sijaan että ne löytyisivät sen jälkeen, kun täysimittainen järjestelmä on rakennettu niitä vasten.
Pidä talon sisäinen insinöörikyvykkyys riittävänä ollakseen älykäs ostaja, vaikka toimitus olisi ulkoistettu. Julkinen elin, joka on ontoksi syönyt teknisen asiantuntemuksensa, ei voi arvioida toimittajan ehdotusta, havaita ongelmallisen hankkeen varhaisia varoitusmerkkejä tai neuvotella tietään ulos lukosta, mitä sen hankintasäännöt paperilla sanovatkin.
Poista perintöjärjestelmän riskiprofiili ennen sen käyttöliittymää. Priorisoi tukemattomien kielten, korjaamattoman infrastruktuurin ja dokumentoimattomien integraatioiden — katkoksia ja tietomurtoja aiheuttavien vikojen — korvaaminen visuaalisen nykyaikaistamisen edelle, joka kantaa paljon vähemmän toiminnallista riskiä.
Mittaa toimituksen terveyttä insinöörin indikaattoreilla, ei vain budjetin ja aikataulun poikkeamalla. Käyttöönottotiheys, vikaluvut ja vanhimman käsittelemättömän teknisen velan kohteen ikä kertovat hallintoneuvostolle enemmän siitä, onnistuuko ohjelma, kuin se, onko se tällä hetkellä budjetissa, mikä on usein viimeinen indikaattori, joka liikkuu.

Kysymyksiä keskusteltavaksi tiimissäsi

Tiedämmekö todella, kuinka paljon teknistä velkaa kannamme, järjestelmä kerrallaan? Useimmat julkiset elimet osaavat sanoa vuoden pääomabudjettinsa mutta eivät voi sanoa mitään varmuudella siitä, kuinka suuri osa niiden ohjelmistokokonaisuudesta toimii tukemattomilla komponenteilla, dokumentoimattomalla logiikalla tai koodilla, jota kukaan jäljellä oleva henkilöstö ei täysin ymmärrä. Käytä tätä kysymystä pyytääksesi jokaista huoneessa olevaa järjestelmän omistajaa arvioimaan rehellisesti, kuinka varma hän on siitä, että hänen tiiminsä voisi turvallisesti muuttaa tärkeintä järjestelmäänsä rikkomatta jotain, mitä kukaan ei ennakoinut. Keskustelkaa siitä, mitä vaadittaisiin noiden arvioiden muuttamiseen todelliseksi rekisteriksi, tarkistettuna kiinteällä syklillä, hiljaisen tiedon sijaan, joka poistuu, kun avainmies lähtee. Pohtikaa myös, kuka tällä hetkellä päättää, kuinka paljon velkaa on hyväksyttävää kantaa, ja onko tuo päätös tietoinen vai oletuksena tehty.

Jos tärkein perintöjärjestelmämme pitäisi korvata alkaen tänään, suunnittelisimmeko kertasiirtymää vai vaiheittaista siirtoa — ja miksi? Vaisto korvata vanha järjestelmä kerralla johtuu usein budjettisykleistä ja ohjelmanhallinnan mukavuudesta eikä teknisestä välttämättömyydestä, ja se keskittää valtavan riskin yhteen hetkeen. Käytä tätä kysymystä käydäksesi konkreettisesti läpi, miltä kuristajaviikunatyyppinen vaiheittainen siirto tärkeimmästä perintöjärjestelmästänne todella näyttäisi, pala palalta. Keskustelkaa siitä, mikä estää teitä valitsemasta tuota reittiä tänään — yhden käyttöönottopäivän ympärille rakennettu rahoitus, hallintoprosessi, joka haluaa yhden siistin virstanpylvään, vai aito tekninen rajoite, joka tekee vaiheittaisen siirron mahdottomaksi tälle järjestelmälle.

Kuka todella omistaa lähdekoodin ohjelmistolle, jonka organisaatiomme on maksanut rakennettavaksi, ja voisimmeko todistaa sen? Monet julkiset elimet huomaavat vasta, kun suhde toimittajaan kiristyy, että sopimus ei koskaan turvannut selvää omistusta tai escrow-järjestelyä koodiin, josta niiden kriittiset palvelut riippuvat. Käytä tätä kysymystä hakeaksesi kolmen tärkeimmän räätälöidyn järjestelmänne sopimukset ja tarkistaaksesi täsmällisesti, mitä kukin sanoo koodin omistuksesta, escrow-järjestelystä ja oikeudesta viedä koodi toiselle toimittajalle. Keskustelkaa siitä, mitä tapahtuisi huomenna, jos ensisijainen toimittajanne kenelle tahansa noista kolmesta järjestelmästä lopettaisi toimintansa tai kieltäytyisi jatkamasta suhdetta.

Missä käytämme oletuksena suljettua, omistusoikeudellista ohjelmistoa tottumuksesta, kun avoin oletuksena -lähestymistapa palvelisi meitä yhtä hyvin tai paremmin? Avoin oletuksena -politiikat ovat olemassa juuri siksi, että useimmat julkiset elimet ratkaisevat päällekkäisiä ongelmia itsenäisesti, kukin maksaen täyden kustannuksen ohjelmistosta, jonka toinen julkinen elin on jo rakentanut ja olisi voinut jakaa. Käytä tätä kysymystä tunnistaaksesi yhden järjestelmän, jota parhaillaan rakennetaan tai määritellään, ja kysyäksesi, onko vastaava jo olemassa avoimen lähdekoodin ohjelmistona muualla hallinnossa, tai voisiko se, jota rakennatte, hyödyllisesti julkaista muiden uudelleenkäytettäväksi. Keskustelkaa siitä, mikä tietty este — tietoturvahuoli, hankintatottumus, selvän politiikan puute — todella estää tuon uudelleenkäytön, sen sijaan että oletettaisiin sen olevan epäolennaista täällä.

Sallivatko hankinta- ja vastuullisuusprosessimme todella rehellisen ketterän toimituksen, vai nimeääkö se vain vesiputouksen virstanpylväät uudelleen sprinteiksi? On yleistä, että tiimi ajaa nimellisesti ketteriä seremonioita samalla kun sitä yhä rahoitetaan, hallinnoidaan ja siitä raportoidaan sopimuksentekohetkellä sovittua kiinteää määrittelyä vasten, mikä luo uudelleen jokaisen vesiputouksen epäonnistumistavan ketterän nimen alla. Käytä tätä kysymystä jäljittääksesi yhden elävän digitaalisen ohjelman sen hankeperustelusta nykyiseen hallintoraportointiinsa ja kysyäksesi, sietäisikö rahoitusrakenne ohjelman suunnan muuttumista sen perusteella, mitä aito varhainen julkaisu opetti. Keskustelkaa siitä, mitä ohjelman rahoituksessa ja raportoinnissa pitäisi muuttua, jotta iteratiivinen toimitus olisi todellista eikä kosmeettista (katso Aihe 3.7 — Julkiset hankinnat ja tilaaminen).

Onko meillä tarpeeksi talon sisäistä insinöörikyvykkyyttä ollaksemme älykäs ostaja järjestelmille, joista riippumme eniten? Organisaatio, joka on ulkoistanut kaiken teknisen harkintansa, ei vain toimituskapasiteettiaan, ei voi kertoa, onko toimittajan ehdotus järkevä, onko hanke hiljaa menossa ongelmiin tai mikä on työn kohtuullinen hinta. Käytä tätä kysymystä kysyäksesi, kuinka moni organisaatiossanne voisi uskottavasti arvioida tärkeimmän järjestelmänne teknistä arkkitehtuuriehdotusta ja miten tuo luku on muuttunut viimeisen viiden vuoden aikana. Keskustelkaa siitä, mitä vaadittaisiin kyvykkyyden uudelleenrakentamiseen, missä se on rapautunut, ja mitä organisaationne menettää, neuvotteluasemassa yhtä paljon kuin toimitusriskissä, jokaisena vuonna, jonka se on ilman.

Käytännössä: esimerkki julkisesta arvosta

Kuvitteellinen alueellinen hallinto — vain havainnollistava, ei kuvaus mistään todellisesta lainkäyttöalueesta — ajoi työttömyysetuushakemuksensa järjestelmän kautta, joka oli kirjoitettu ensimmäisen kerran yli kolmekymmentä vuotta aiemmin ja jota ylläpiti yhä pienempi joukko insinöörejä, jotka ymmärsivät sen alkuperäisen ohjelmointikielen. Hakemusmäärä oli kasvanut selvästi yli sen, mitä järjestelmän suunnittelijat olivat ennakoineet, yöllinen käsittelyajo epäonnistui yhä useammin valmistumaan ennen aamun tapahtumien alkua, ja viraston teknologiajohto varoitti, että etuusmaksuihin vaikuttava suunnittelematon katkos oli nyt kysymys milloin, ei jos.

Viraston ensimmäinen vaisto oli tavanomainen vastaus ongelmaan, joka tuntui kiireelliseltä: tilata yksi suuri sopimus koko järjestelmän korvaamiseksi nykyaikaisella alustalla, täysin etukäteen määriteltynä, toimitettuna kahden vuoden kiinteällä aikataululla yhdellä siirtymäviikonlopulla lopussa. Viraston tarkastusvaliokunnan tilaama toteutusta edeltävä katsaus nosti esiin vaikean kysymyksen ennen sopimuksen allekirjoittamista: mitä tapahtuisi satojentuhansien hakijoiden etuusmaksuille, jos uudessa järjestelmässä olisi löytämätön vika sen ensimmäisellä täysimittaisen käytön viikolla, vanhan järjestelmän ollessa jo poistettu käytöstä eikä paluuta olisi.

Virasto muutti suuntaa. Se piti perintöjärjestelmän käynnissä virallisena järjestelmänä ja alkoi rakentaa uutta hakemusten vastaanotto- ja kelpoisuusarviointitoiminnallisuutta sen rinnalle kuristajaviikunamallilla: jokainen uusi moduuli julkaistiin ensin pienelle prosenttiosuudelle uusista hakemuksista, varmennettiin vanhan järjestelmän rinnakkaista tulostetta vasten ja laajennettiin vasta, kun sen tulokset täsmäsivät. Kahdeksassatoista kuukaudessa suurin osa uusista hakemuksista kulki nykyaikaisten komponenttien kautta samalla kun alkuperäinen järjestelmä käsitteli kutistuvaa jäännöskantaa, ja minkä tahansa yksittäisen tapauksen voi reitittää takaisin vanhalle polulle, jos jokin näytti väärältä. Virasto vaati myös jokaisessa tätä työtä varten annetussa uudessa sopimuksessa, että lähdekoodi on viraston omistuksessa ja julkaistaan avoimena lähdekoodina tietoturvatarkastuksen valmistuttua, jotta muut alueelliset hallitukset, jotka kohtasivat saman ikääntyvän keskuskoneongelman, voisivat mukauttaa komponentit sen sijaan että toistaisivat saman rakentamisen tyhjästä.

Perintöjärjestelmän viimeisten jäännöstoimintojen täydellinen korvaaminen kesti lähes neljä vuotta — paperilla pidempään kuin alkuperäinen kahden vuoden kertasiirtosuunnitelma lupasi. Mutta yksikään hakija ei kokenut suunnittelematonta katkosta siirtymän aikana, jokainen lisäys oli tarpeeksi pieni peruutettavaksi tunneissa, kun vika löydettiin, ja kaksi naapurialueellista hallintoa alkoi mukauttaa viraston julkaistua kelpoisuusarviointikoodia omiin järjestelmiinsä ensimmäisen julkaisuvuoden kuluessa.

Neljä sektorinäkökulmaa

Paikallishallinto

Paikallishallinto ajaa tyypillisesti suurta määrää pienempiä, erillään olevia järjestelmiä muutaman kansallisen mittakaavan alustan sijaan, mikä tarkoittaa, että tekninen velka kertyy monien erikseen hankittujen, erikseen ylläpidettyjen sovellusten yli yhden näkyvän lippulaivajärjestelmän sijaan. Paikallisviranomaisilla on yleensä vähiten talon sisäistä insinöörikyvykkyyttä mistään hallinnon tasosta, mikä tekee perustelusta konfiguroitavan hyödykeohjelmiston ostamiselle räätälöidyn rakentamisen sijaan erityisen vahvan, ja tekee jaetuista alueellisista tai kansallisista alustoista — Aiheen 5.1 aihe (katso Aihe 5.1 — Digitaalinen hallinto ja digitaalinen muutos) — erityisen arvokkaan reitin välttää kunkin viranomaisen saman kyvykkyyden erillinen uudelleenrakentaminen.

Valtionhallinto

Valtionhallinto on paikka, jossa vanhimmat ja seurauksellisimmat perintöjärjestelmät tapaavat sijaita — keskeinen vero-, sosiaalivakuutus- ja etuushallinto — koska nämä olivat usein hallinnon ensimmäisiä laajamittaisia tietokoneistamishankkeita ja kantavat nyt korkeimmat panokset minkä tahansa nykyaikaistamisen epäonnistumiselle. Valtionhallinnolla on tyypillisesti erikoistunut kaupallinen ja insinöörikyvykkyys ajaa aidosti vaiheittaista nykyaikaistamisohjelmaa ja neuvotella todellinen koodin omistus sopimuksiinsa, ja se on yleensä hallinnon taso, joka on parhaiten sijoitettu asettamaan avoin oletuksena -politiikka riittävällä mittakaavalla, jotta hallinnon laajuinen uudelleenkäyttö todella tapahtuu.

Kolmas sektori ja voittoa tavoittelematon toiminta

Voittoa tavoittelemattomat organisaatiot ja hyväntekeväisyysjärjestöt rakentavat harvoin suuria räätälöityjä alustoja itse, mutta ne ovat usein vastaanottavana osapuolena ohjelmistolle, jonka valtion rahoittaja on tilannut tai määrännyt — raportointiportaali, tapausten hallintajärjestelmä, jota avustus tai sopimus vaatii niitä käyttämään — vähäisellä vaikutusvallalla sen suunnitteluun, tekniseen velkaan tai toimittajaan. Kolmannen sektorin organisaatio, joka riippuu valtion määräämästä järjestelmästä, perii tuon järjestelmän epäonnistumistavat perimättä mitään vipuvoimaa niiden korjaamiseen, mikä on yksi syy lisää, miksi lopputulospohjaisten rahoitussuhteiden täytyy ottaa huomioon määrätyn teknologian toiminnallinen taakka (katso Aihe 3.7 — Julkiset hankinnat ja tilaaminen), ei vain itse lopputulosmittaria.

Monenkeskinen ja kansainvälinen

Monenkeskiset elimet ja kehitysvirastot edistävät yhä enemmän yhden maan julkishallintoa varten rakennettua ohjelmistoa uudelleenkäytettävänä digitaalisena julkishyödykkeenä, jota muut maat voivat mukauttaa, sen sijaan että kukin hallitus tilaisi vastaavan järjestelmän yksityiseltä toimittajalta täydellä kustannuksella. Erityinen riski täällä on, että yhden maan oikeudelliseen ja hallinnolliseen kontekstiin rakennettu digitaalinen julkishyödyke voidaan ottaa käyttöön muualla liian vähäisellä mukauttamisella, tuoden oletuksia — tunnistamisesta, kelpoisuudesta tai prosessista — jotka eivät todellisuudessa siirry; jaetun, avoimen infrastruktuurin lupaus on todellinen, mutta vain missä aito paikallinen mukauttamiskapasiteetti kulkee koodin mukana.

Yleisiä epäonnistumistapoja

Kertasiirtymä, joka epäonnistuu käyttöönotossa. Kriittinen perintöjärjestelmä korvataan yhdellä, peruuttamattomalla siirtymällä vuosien kehityksen jälkeen ilman elävää tuotantoaltistusta, ja vika, joka ilmenee vain todellisessa mittakaavassa tai reunatapauksessa, jota kukaan ei testannut, nousee esiin täyden toiminnan ensimmäisenä päivänä ilman mahdollisuutta palata vanhaan järjestelmään, koska se on jo poistettu käytöstä. Kustannus mitataan menetettyinä maksuina, evättyinä palveluina tai katkoksina, jotka vaikuttavat täsmälleen niihin kansalaisiin, joita varten järjestelmä on olemassa, pahimmalla mahdollisella hetkellä — hetkellä, jona kaikki luottivat korvaavan järjestelmän toimivan.

Hiljainen teknisen velan kertyminen. Määräaikapaine voittaa toistuvasti argumentin tunnettujen oikopolkujen korjaamiseen tarvittavaa aikaa vastaan, ja jokainen lykkäys on yksittäin puolustettavissa, kunnes kertynyt velka tekee jopa pienen muutoksen suhteettoman kalliiksi ja riskialttiiksi. Kustannus ilmenee vuosia myöhemmin järjestelmänä, jota kukaan ei voi turvallisesti muuttaa, työvoimana, joka on hiljaa lakannut yrittämästä mitään muuta kuin kiireellisimpiä paikkauksia, ja lopulta nykyaikaistamisohjelmana, joka on paljon suurempi ja kalliimpi kuin jatkuva, pienempi uudistaminen olisi ollut.

Toimittajalukko stabiiliutena luultuna. Julkinen elin uusii saman toimittajan sopimuksen toistuvasti, koska vaihtaminen näyttää liian häiritsevältä yrittää, koskaan testaamatta, mitkä todelliset vaihtokustannukset olisivat, tai neuvottelematta koodin omistuksesta ja avoimista tietomuodoista, jotka pitäisivät nuo kustannukset hallittavina. Kustannus on pysyvästi heikentynyt neuvotteluasema hinnasta ja ehdoista, joka huomataan vasta, kun toimittajan palvelun laatu laskee tai sen hinnoittelu nousee ja julkinen elin havaitsee, ettei sillä ole uskottavaa vaihtoehtoa.

Kosmeettinen ketteryys. Toimitustiimi ottaa käyttöön ketterät seremoniat — päivittäispalaverit, sprintit, tehtäväluettelon — kun taustalla oleva sopimus, rahoitus ja hallintorakenne yhä olettavat kiinteän määrittelyn ja yhden etene/älä etene -virstanpylvään, joten tiimi raportoi sprinttinopeutta samalla kun se todellisuudessa toimittaa vesiputoussuunnitelmaa vasten sen alla. Kustannus on, ettei mikään ketteryyden aidoista hyödyistä — varhainen käyttäjäpalaute, joka muuttaa suuntaa, riski esiin varhain — toteudu, samalla kun nykyaikaisen käytännön ulkonäkö tekee taustalla olevasta jäykkyydestä vaikeamman valvontaelinten nähdä ja haastaa.

Avoimen lähdekoodin politiikka ilman ylläpitosuunnitelmaa. Julkinen elin julkaisee lähdekoodin täyttääkseen avoin oletuksena -politiikan mutta käsittelee julkaisua kertaluonteisena vaatimustenmukaisuusaskeleena, ilman resursointia ulkoisten kontribuutioiden tarkastamiseen, haavoittuvuuksien korjaamiseen tai dokumentaation ylläpitoon. Kustannus on julkaistu tietovarasto, joka näyttää avoimelta mutta toimii ylläpitämättömänä umpikujana, mikä vahingoittaa luottamusta laajempaan avoin oletuksena -ohjelmaan enemmän kuin julkaisematta jättäminen olisi tehnyt.

Kypsyysmalli

Osa-alue	Aloittava	Kehittyvä	Vakiintunut	Hallittu	Koordinoitu
Tekninen velka on näkyvää ja hallittua	Velka on dokumentoimatonta ja tunnettua vain epävirallisesti yksittäisille insinööreille	Osittainen inventaario on olemassa joillekin järjestelmille, ei tarkistettu kiinteällä syklillä	Velkarekisteri kattaa kaikki kriittiset järjestelmät ja sitä tarkistetaan dokumentoidulla syklillä	Velan vähentäminen on rahoitettu ja sitä seurataan mitattavia tavoitteita vasten	Velkadataa jaetaan organisaation koko kokonaisuuden yli nykyaikaistamisinvestointien priorisoimiseksi
Perintöjärjestelmien nykyaikaistaminen välttää kertasiirtymän riskin	Korvaamisen oletetaan tarkoittavan yhtä täyttä uudelleenkirjoitusta ja siirtymää	Vaiheittaisia lähestymistapoja käytetään satunnaisesti ilman johdonmukaista menetelmää	Kuristajaviikuna-tyylinen vaiheittainen siirto on dokumentoitu oletus kriittisille järjestelmille	Siirron edistymistä ja peruutusvalmiutta mitataan ja siitä raportoidaan aktiivisesti	Nykyaikaistamismenetelmää ja työkaluja jaetaan ja parannetaan vertaisten julkisten elinten kesken
Rakenna vai osta -päätökset ovat tietoisia	Rakennus tai osto valitaan tottumuksesta tai toimittajasuhteesta, ei arvioida	Jonkin verran arviointia tapahtuu, epäjohdonmukaisesti, ennen suuria ohjelmistopäätöksiä	Dokumentoitua päätöskehystä sovelletaan jokaiseen merkittävään rakenna vai osta -valintaan	Rakenna vai osta -lopputuloksia seurataan alkuperäistä perustelua vasten ajan yli	Rakenna vai osta -kyvykkyyttä ja oppeja jaetaan muiden julkisten elinten kanssa, jotka kohtaavat saman valinnan
Lähdekoodi ja data ovat avoimia oletuksena	Suljettu, omistusoikeudellinen toimitus on kyseenalaistamaton oletus	Avoimeksi julkaiseminen tapahtuu satunnaisesti, yksittäisten tiimien ajamana	Avoin oletuksena -politiikka on dokumentoitu ja sitä sovelletaan johdonmukaisesti	Julkaistua koodia ylläpidetään aktiivisesti, resursoiden ulkoisten kontribuutioiden käsittelyyn	Julkaistua koodia käytetään uudelleen hallinnon yli ja muiden lainkäyttöalueiden toimesta, uudelleenkäyttöä seurataan hyötynä
Toimitustapa sopii vastuullisuusrakenteeseen	Sopimukset ja hallinto olettavat vesiputouksen riippumatta siitä, miten toimitus todella tapahtuu	Ketteriä seremonioita käytetään, mutta rahoitus ja hallinto portittavat yhä kiinteän määrittelyn	Sopimukset ja rahoitusportit rakennetaan osoitetun toimivan ohjelmiston ympärille	Toimituksen terveyttä mitataan insinöörin indikaattoreilla, ei vain budjetin ja aikataulun poikkeamalla	Hankinta- ja vastuullisuussääntöjä mukautetaan aktiivisesti, näytön perusteella, sopimaan iteratiiviseen toimitukseen

Tarkistuslista

Inventoi jokaisen kriittisen järjestelmän tekninen velka ja tarkista rekisteri kiinteällä syklillä.
Sovella dokumentoitua rakenna vai osta -kehystä ennen sitoutumista mihin tahansa merkittävään uuteen ohjelmistoon.
Käytä minkä tahansa perintöjärjestelmän korvaamiseen oletuksena vaiheittaista siirtomenetelmää ja vaadi eksplisiittinen perustelu kertasiirtymälle.
Varmista lähdekoodin omistus- tai escrow-ehdot jokaisessa ohjelmistosopimuksessa ennen allekirjoitusta.
Julkaise lähdekoodi avoin oletuksena -politiikan alla, dokumentoidulla poikkeusprosessilla.
Resursoi jatkuva ylläpito jokaiselle tuon politiikan alla julkaistulle tietovarastolle, ei vain sen ensimmäiselle julkaisulle.
Vaadi avoimet, dokumentoidut tietomuodot silloinkin, kun taustalla oleva ohjelmisto on omistusoikeudellista.
Rakenna rahoitusportit osoitetun toimivan ohjelmiston ympärille yhden kiinteän määrittelyn virstanpylvään sijaan.
Rakenna ja testaa minimaalinen elinkelpoinen tuote oikeilla käyttäjillä ennen täyteen laajuuteen sitoutumista.
Seuraa käyttöönottotiheyttä, vikalukuja ja avointa teknistä velkaa pysyvinä hallintoindikaattoreina.
Arvioi talon sisäinen insinöörikyvykkyys sitä vasten, mitä tarvitaan älykkääksi ostajaksi, ja sulje tunnistetut aukot.
Priorisoi tukematon infrastruktuuri ja dokumentoimattomat integraatiot kosmeettisen nykyaikaistamisen edelle.

Keskeiset lähteet

GOV.UK Service Standard, Government Digital Service, Yhdistynyt kuningaskunta — kansallinen digitaalinen palvelustandardi, joka vaatii iteratiivista, käyttäjälähtöistä toimitusta ja avoimia standardeja julkisille palveluille.
Office of Management and Budget, Federal Source Code Policy (M-16-21), Yhdysvallat — liittovaltion politiikka, joka vaatii virastoja harkitsemaan uudelleenkäyttöä ja avoimen lähdekoodin julkaisua räätälöidylle valtion ohjelmistolle.
Free Software Foundation Europe, Public Money, Public Code -kampanja — eurooppalaiselle yleisölle kehitetty perustelu julkisesti rahoitetun ohjelmiston lähdekoodin julkaisemiselle vapailla ja avoimen lähdekoodin lisensseillä.
Ward Cunningham, ”The WyCash Portfolio Management System” (OOPSLA 1992 -kokemusraportti) — teknisen velan vertauskuvan alkuperäinen esitys.
Digital Public Goods Alliance — monitoimijainen aloite, joka ylläpitää standardeja ja rekisteriä avoimelle ohjelmistolle, datalle ja sisällölle, joka on suunniteltu palvelemaan julkisia kehitystavoitteita.

Viitteet

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/