Mjukvaruutveckling och plattformar i offentlig sektor

Varför detta är viktigt för offentligt värde

Nästan varje offentlig tjänst en medborgare möter i dag – att registrera en födsel, ansöka om en förmån, betala en skatteräkning, boka en rättegångstid – körs på programvara någonstans bakom disken eller skärmen. Den programvaran är sällan ett engångsköp; den blir en del av statens permanenta infrastruktur, och överlever ofta den administration som beställde den, den leverantör som byggde den och det programmeringsspråk dess ingenjörer utbildades i. Ett offentligt organ upplever inte programvara som det upplever en byggnad eller en väg, där tillgångens skick är synligt; programvara förfaller osynligt, och räkningen för förfallet anländer år senare som en nödsituation.

Spänningen som driver det här ämnet är strukturell. Programvara är till sin natur iterativ – krav blir tydligare när användare interagerar med ett fungerande system, och den bästa ingenjörspraxisen är att bygga något litet, lära sig och anpassa. Offentlig upphandling och offentligt ansvarsutkrävande (se Ämne 3.7 — Offentlig upphandling och beställning) byggdes däremot för kapitalarbeten och försvarsavtal: en fast specifikation, en enda stor tilldelning, betalning vid milstolpar och ett affärscase som godkänts år innan leveransen börjar. När en lagstiftande församling eller en revisor förväntar sig ett fastprisavtal med fast omfattning och ett ingenjörsteam behöver ändra kurs efter den första releasen visar sig missanpassningen som skopglidning, budgetöverskridande eller ett system som specificerades rätt 2019 och är föråldrat när det levereras.

De plattformar som det här ämnets ingenjörspraxis finns för att bygga – delade identitetssystem, betalningsstråk, ärendehanteringsverktyg som återanvänds över förvaltningar – är föremål för Ämne 5.1 (se Ämne 5.1 — Digital förvaltning och digital omställning); det här ämnet handlar om disciplinen att bygga och köpa den programvara som gör vilken sådan plattform som helst, eller vilken enskild tjänst som helst, tillförlitlig, utbytbar och ägd av det offentliga organ som är beroende av den, snarare än av den leverantör som råkade skriva den först.

Grundläggande begrepp

Beslutet att bygga eller köpa är valet mellan att beställa skräddarsydd programvara skriven för en organisations behov och att anta konfigurerbar standardprogramvara som redan byggts för en marknad av liknande köpare. Att köpa är vanligen billigare och mindre riskfyllt för ett behov som inte är genuint särpräglat – löner, e-post, standardiserad ärendehantering – medan att bygga bara är motiverat där kravet skiljer sig tillräckligt för att ingen konfigurerbar produkt passar, eller där förmågan i sig är en strategisk tillgång organisationen behöver äga och utveckla.

Teknisk skuld (technical debt) är en metafor, myntad av programvaruingenjören Ward Cunningham 1992, för den ackumulerade kostnaden av att välja ett snabbt sätt att leverera programvara nu framför ett grundligare som hade tagit längre tid. Teknisk skuld är, liksom finansiell skuld, inte i sig fel att ta på sig – Cunninghams egen poäng var att leverera fungerande kod snabbt och refaktorera efteråt kan vara rätt beslut – men skuld som aldrig betalas av drar på sig ränta i form av långsammare leverans, fler fel och växande risk, och ett offentligt organ som inte kan se sin skuld kan inte avgöra om det ska amortera den eller låta den växa.

Ett äldre system (legacy system) är en gammal teknik, tillämpning eller plattform som förblir i aktiv användning trots att den är föråldrad, ofta därför att ersättning är dyr eller därför att ingen kvar i organisationen helt förstår vad den gör. Äldre system är särskilt ihärdiga i staten: centrala skatte-, förmåns- och socialförsäkringssystem skrivna för decennier sedan i språk som COBOL – Common Business-Oriented Language, utformat 1960 för administrativ databehandling – hanterar fortfarande transaktioner för miljontals medborgare, eftersom systemen fungerar och den institutionella kunskap som behövs för att säkert avveckla dem ofta har gått i pension före dem.

Programvarumodernisering är den allmänna termen för att konvertera, skriva om eller migrera ett äldre system till en aktuell arkitektur, ett aktuellt språk eller en aktuell plattform. Programvarumodernisering spänner från en fullständig omskrivning till mer konservativa alternativ såsom att köra samma kod på modern infrastruktur, och valet mellan dem är lika mycket ett riskhanteringsbeslut som ett tekniskt.

Strypfikonmönstret (strangler fig pattern) är ett inkrementellt moderniseringssätt, uppkallat efter en växt som slingrar sig runt ett värdträd och gradvis ersätter det, där ny funktionalitet byggs vid sidan av ett äldre system och trafiken omdirigeras till den bit för bit, i stället för att ersätta hela systemet i en enda övergång. Strypfikonmönstret spelar roll eftersom det låter varje steg prövas, backas eller pausas utan att hela tjänsten tas ner – motsatsen till en big-bang-ersättning, där det gamla systemet stängs av och det nya slås på i ett enda ögonblick utan väg tillbaka om något är fel.

Leverantörsberoende (vendor lock-in) uppstår när en kund blir så beroende av en leverantörs proprietära teknik, dataformat eller avtalsvillkor att ett byte till en annan leverantör medför oöverkomlig kostnad eller risk. Leverantörsberoende är en särskild fara i offentlig programvara eftersom köparen är en återkommande kund med begränsad praktisk möjlighet att gå därifrån från ett system som kör en kritisk tjänst, vilket försvagar dess förhandlingsposition vid varje efterföljande förnyelse.

Fri programvara och öppen källkod är programvara som distribueras under en licens som ger användare frihet att använda, studera, ändra och vidaredistribuera källkoden. Fri programvara och öppen källkod ligger till grund för en policy om öppen källkod som standard, under vilken ett offentligt organ som utgångspunkt publicerar den källkod det beställer om inte ett särskilt skäl – säkerhetskänslighet, tredje parts rättigheter – motiverar att hålla tillbaka den; motiveringen sammanfattas vanligen som ”offentliga pengar, offentlig kod”: programvara som betalats en gång med offentliga medel bör inte behöva betalas igen, i en annan jurisdiktion, av ett annat offentligt organ som löser samma problem.

Ett digitalt allmängods (digital public good) är öppen programvara, öppna data eller öppet innehåll, släppt under en öppen licens, utformat för att bidra till ett offentligt utvecklings- eller styrningsmål snarare än att generera kommersiell avkastning. Digitala allmängods omramar en regerings öppna utgivning som en del av en bredare, delad infrastruktur som andra regeringar och civilsamhällesorganisationer kan använda direkt, inte bara en intern transparensgest.

Agil programvaruutveckling är ett paraplybegrepp för iterativa angreppssätt för att bygga programvara som föredrar fungerande programvara, frekvent leverans och att svara på förändring framför att följa en i förväg överenskommen fast plan. Agil programvaruutveckling står i kontrast till vattenfallsmodellen, ett sekventiellt angreppssätt där krav, design, bygge och prövning vart och ett slutförs helt innan nästa börjar; vattenfallets lockelse för offentliga organ har alltid varit att dess milstolpar passar prydligt mot ett fastprisavtal och en årlig budgetcykel, vilket är skälet till att så mycket upphandlingsrätt fortfarande förutsätter det, även där leveransen genuint är agil.

En minsta livskraftig produkt (minimum viable product) är den minsta version av en tjänst som kan släppas till verkliga användare för att pröva om den fungerar och lära sig vad som ska byggas härnäst. Begreppet minsta livskraftiga produkt, anpassat i offentliga spelböcker för digitala tjänster, ger ett iterativt team ett försvarbart sätt att visa en finansiär eller en revisor något verkligt och fungerande långt innan full omfattning är klar – förutsatt att ansvarsutkrävandeprocessen accepterar en genuint minimal release snarare än att behandla den som den färdiga produkten under ett annat namn.

Bästa praxis

1. Köp som utgångspunkt för odifferentierade behov, och reservera byggande för det som genuint är särpräglat. Löner, e-post och allmänna ärendehanteringsbehov skiljer sig sällan tillräckligt från någon annan organisations för att motivera skräddarsydd programvara; bygg bara där kravet, skalan eller behovet av att äga och utveckla förmågan under decennier genuint skiljer sig från vad marknaden erbjuder.
2. Gör teknisk skuld synlig innan du avgör hur mycket av den du ska bära. För ett register över kända genvägar, uppskjutna rättelser och stödlösa beroenden för varje system i drift, granskat enligt en fast cykel, så att det blir en medveten avvägning att bära skuld ytterligare ett år snarare än att ingen tittar.
3. Planera aldrig en enda, oåterkallelig övergång som den enda vägen bort från ett kritiskt äldre system. Föredra inkrementella angreppssätt såsom strypfikonmönstret som låter varje del prövas, backas och rullas ut gradvis; en big-bang-ersättning av ett system som miljontals är beroende av koncentrerar års risk till en enda helg utan väg tillbaka om något fallerar.
4. Behandla den källkod din organisation betalar för att få skriven som en tillgång den äger, inte en tjänst den hyr. Förhandla källkodsdeposition (escrow) eller regelrätt ägande vid avtalsslutet, inte efter att en tvist har börjat, eftersom en leverantör som håller den enda kopian av din kritiska tjänsts kod är leverantörsberoende av design.
5. Publicera källkod som öppen som standard, och kräv ett särskilt skäl för att hålla tillbaka den. En policy om öppen källkod som standard, tillämpad konsekvent, förvandlar varje förvaltnings skräddarsydda programvara till en delad tillgång över hela staten snarare än en engångskostnad, och låter externa experter hitta säkerhetsbrister som ett internt team ensamt skulle missa.
6. Skriv programvaruavtal som gör iterativ leverans rättsligt möjlig, inte bara tekniskt möjlig. Ett avtal som bara betalar mot en fast specifikation överenskommen vid undertecknandet tvingar ett team att välja mellan ärlig agil praxis och avtalsenlig efterlevnad; använd i stället stegvisa finansieringsportar knutna till demonstrerad fungerande programvara i stället för en milstolpe i slutet.
7. Finansiera modernisering som ett löpande program, inte ett engångsprojekt av kapitalkaraktär. Ett äldre system som moderniserats en gång och sedan lämnats i ytterligare tjugo år ackumulerar samma risk som det började med; budgetera för kontinuerlig, inkrementell förnyelse på det sätt en vägmyndighet budgeterar för omasfaltering, inte en storslagen ersättning en gång per generation.
8. Välj öppna standarder och portabla dataformat även när du köper kommersiell programvara. Att kräva att en leverantörs system lagrar och exporterar data i öppna, dokumenterade format håller bytekostnaderna låga även där själva programvaran är proprietär, och är ofta ett mer uppnåeligt skydd på kort sikt mot leverantörsberoende än att insistera på att varje system ska vara öppen källkod.
9. Bygg en minsta livskraftig produkt och visa den för verkliga användare innan du förbinder dig till full omfattning. Att släppa en genuint minimal version och sedan iterera på det som lärts fångar felaktiga antaganden medan de fortfarande är billiga att rätta, i stället för efter att ett fullskaligt system har byggts mot dem.
10. Behåll tillräcklig ingenjörskapacitet i egen regi för att vara en kunnig köpare, även där leveransen läggs ut. Ett offentligt organ som har urholkat sin tekniska expertis kan inte bedöma en leverantörs förslag, upptäcka tidiga varningstecken på ett projekt i trubbel eller förhandla sig ur ett leverantörsberoende, vad dess upphandlingsregler än säger på pappret.
11. Avveckla ett äldre systems riskprofil före dess användargränssnitt. Prioritera ersättning av språk som inte längre stöds, opatchad infrastruktur och odokumenterade integrationer – de fel som orsakar avbrott och intrång – före visuell modernisering som medför långt mindre operativ risk.
12. Mät leveranshälsa med tekniska indikatorer, inte bara budget- och tidsavvikelse. Driftsättningsfrekvens, felfrekvens och åldern på det äldsta oadresserade objektet med teknisk skuld säger en styrelse mer om huruvida ett program kommer att lyckas än om det för närvarande håller budget, ofta den sista indikatorn som rör sig.

Frågor att diskutera med ditt team

Vet vi faktiskt hur mycket teknisk skuld vi bär, system för system? De flesta offentliga organ kan ange sin kapitalbudget för året men kan inte med någon säkerhet ange hur stor del av deras programvarubestånd som körs på komponenter som inte längre stöds, odokumenterad logik eller kod som ingen återstående personal fullt ut förstår. Använd frågan för att be varje systemägare i rummet uppskatta, ärligt, hur säkra de är på att deras team säkert kunde ändra deras mest kritiska system utan att bryta något ingen förutsåg. Diskutera vad som skulle krävas för att förvandla de uppskattningarna till ett faktiskt register, granskat enligt en fast cykel, i stället för tyst kunskap som försvinner när en nyckelingenjör gör det. Fundera också på vem som i dag avgör hur mycket skuld som är acceptabelt att bära, och om det beslutet är medvetet eller sker av förbiseende.

Om vårt mest kritiska äldre system behövde ersättas med början i dag, skulle vi planera en big-bang-övergång eller en inkrementell migrering – och varför? Instinkten att ersätta ett gammalt system på en gång drivs ofta av budgetcykler och programledningens bekvämlighet snarare än teknisk nödvändighet, och den koncentrerar enorm risk till ett enda ögonblick. Använd frågan för att konkret gå igenom hur en inkrementell migrering i strypfikonstil av ert mest kritiska äldre system faktiskt skulle se ut, bit för bit. Diskutera vad som hindrar er från att välja den vägen i dag – finansiering strukturerad kring ett enda lanseringsdatum, en styrningsprocess som vill ha en ren milstolpe eller en genuin teknisk begränsning som gör inkrementell migrering omöjlig för det här systemet.

Vem äger faktiskt källkoden till den programvara vår organisation har betalat för att få byggd, och skulle vi kunna bevisa det? Många offentliga organ upptäcker, först när en relation till en leverantör surnar, att avtalet aldrig säkrade tydligt ägande eller deposition av den kod deras kritiska tjänster är beroende av. Använd frågan för att dra fram avtalen för era tre viktigaste skräddarsydda system och kontrollera specifikt vad var och en säger om kodägande, deposition och rätten att ta koden till en annan leverantör. Diskutera vad som skulle hända i morgon om er huvudleverantör för något av de tre systemen gick i konkurs eller vägrade fortsätta relationen.

Var väljer vi som standard stängd, proprietär programvara av vana, när ett angreppssätt med öppen källkod som standard skulle tjäna oss lika bra eller bättre? Policyer om öppen källkod som standard finns just därför att de flesta offentliga organ löser överlappande problem självständigt och var och en betalar hela kostnaden för programvara som ett annat offentligt organ redan har byggt och kunde ha delat. Använd frågan för att identifiera ett system som just nu byggs eller specificeras och fråga om en motsvarighet redan finns som öppen källkod någon annanstans i staten, eller om det ni bygger kunde släppas till nytta för andra att återanvända. Diskutera vilket särskilt hinder – säkerhetsoro, upphandlingsvana, avsaknad av en tydlig policy – som faktiskt stoppar den återanvändningen, i stället för att anta att den inte är relevant här.

Tillåter vår upphandlings- och ansvarsprocess faktiskt ärlig agil leverans, eller märker den bara om vattenfallsmilstolpar till sprintar? Det är vanligt att ett team kör nominellt agila ceremonier medan det fortfarande finansieras, styrs och rapporterar mot en fast specifikation överenskommen vid avtalsslutet, vilket återskapar varje vattenfallsfelmönster under en agil etikett. Använd frågan för att spåra ett levande digitalt program från dess affärscase genom dess nuvarande styrningsrapportering och fråga om finansieringsstrukturen skulle tåla att programmet ändrade riktning utifrån vad en genuin tidig release lärde det. Diskutera vad som skulle behöva förändras i hur programmet finansieras och rapporteras för att iterativ leverans ska vara verklig snarare än kosmetisk (se Ämne 3.7 — Offentlig upphandling och beställning).

Har vi tillräcklig ingenjörskapacitet i egen regi för att vara en kunnig köpare av de system vi är mest beroende av? En organisation som har lagt ut hela sitt tekniska omdöme, inte bara sin leveranskapacitet, kan inte avgöra om en leverantörs förslag är sunt, om ett projekt i det tysta är på väg mot trubbel eller vad ett rimligt pris för arbetet faktiskt är. Använd frågan för att fråga hur många i er organisation som trovärdigt kunde granska ett tekniskt arkitekturförslag för ert viktigaste system, och hur det antalet har förändrats under de senaste fem åren. Diskutera vad som skulle krävas för att återuppbygga den förmågan där den har eroderat, och vad er organisation förlorar, i förhandlingsposition lika mycket som i leveransrisk, för varje år den går utan.

I praktiken: ett exempel på offentligt värde

En fiktiv regional regering – illustrativ endast, ingen beskrivning av någon verklig jurisdiktion – körde sina arbetslöshetsersättningsansökningar genom ett system som först skrivits för mer än trettio år sedan, underhållet av ett krympande antal ingenjörer som förstod dess ursprungliga programmeringsspråk. Ansökningsvolymen hade vuxit långt utöver vad systemets utformare hade förutsett, nattliga bearbetningskörningar misslyckades alltmer ofta med att slutföras innan morgonens transaktioner började, och myndighetens teknikledning varnade för att ett oplanerat avbrott som drabbade förmånsutbetalningar nu var en fråga om när, inte om.

Myndighetens första instinkt var en konventionell reaktion på ett problem som kändes brådskande: beställa ett enda stort avtal för att ersätta hela systemet med en modern plattform, specificerad i sin helhet i förväg, levererad mot en fast tidsplan på två år med en enda övergångshelg i slutet. En förhandsgranskning beställd av myndighetens revisionsutskott ställde en svår fråga innan avtalet skrevs under: vad skulle hända med förmånsutbetalningar till flera hundra tusen sökande om det nya systemet hade ett oupptäckt fel under sin första vecka av fullskalig, levande drift, med det gamla systemet redan avvecklat och ingen väg tillbaka.

Myndigheten ändrade kurs. Den behöll det äldre systemet i drift som registerförande system och började bygga ny funktionalitet för ansökningsintag och behörighetsbedömning vid sidan av det, med ett strypfikonangreppssätt: varje ny modul släpptes först till en liten andel nya ansökningar, verifierades mot det gamla systemets parallella utdata och utvidgades först när resultaten stämde. Inom arton månader kördes majoriteten av nya ansökningar genom moderna komponenter medan det ursprungliga systemet hanterade ett krympande restflöde, med möjlighet att dirigera om vilket enskilt ärende som helst tillbaka till den gamla vägen om något såg fel ut. Myndigheten krävde också, i varje nytt avtal som utfärdades för detta arbete, att källkoden skulle ägas av myndigheten och publiceras som öppen källkod så snart säkerhetsgranskningen var klar, så att andra regionala regeringar som stod inför samma problem med åldrande stordatorer kunde anpassa komponenterna i stället för att upprepa samma bygge från början.

Den fullständiga ersättningen av det äldre systemets sista kvarvarande funktioner tog nästan fyra år – längre, på pappret, än den ursprungliga big-bang-planen på två år utlovade. Men ingen sökande upplevde någonsin ett oplanerat avbrott under övergången, varje steg var litet nog att backas inom timmar när ett fel hittades, och två grannregioner började anpassa myndighetens publicerade behörighetsbedömningskod för sina egna system inom det första året efter dess utgivning.

Fyra sektorperspektiv

Lokal förvaltning

Lokal förvaltning kör vanligen ett stort antal mindre, osammanhängande system snarare än en handfull plattformar i nationell skala, vilket innebär att teknisk skuld ackumuleras över många separat upphandlade, separat underhållna tillämpningar snarare än i ett synligt flaggskeppssystem. Kommuner har vanligen minst ingenjörskapacitet i egen regi av någon nivå i staten, vilket gör argumentet för att köpa konfigurerbar standardprogramvara framför skräddarsydda bygg särskilt starkt, och gör delade regionala eller nationella plattformar – föremål för Ämne 5.1 (se Ämne 5.1 — Digital förvaltning och digital omställning) – till en särskilt värdefull väg för att undvika att varje myndighet separat bygger om samma förmåga.

Nationell förvaltning

Nationell förvaltning är där de äldsta och mest följdtunga äldre systemen tenderar att finnas – centrala skatte-, socialförsäkrings- och förmånsadministrationer – eftersom dessa ofta var bland statens första storskaliga datoriseringsinsatser och nu bär de högsta insatserna för varje moderniseringsmisslyckande. Nationell förvaltning har vanligen den specialiserade kommersiella och tekniska kapacitet som krävs för att driva ett genuint inkrementellt moderniseringsprogram och för att förhandla in verkligt kodägande i sina avtal, och är vanligen den nivå i staten som är bäst placerad att fastställa en policy om öppen källkod som standard med tillräcklig skala bakom sig för att åstadkomma faktisk återanvändning över hela staten.

Social sektor och ideell sektor

Ideella organisationer och välgörenhetsorganisationer bygger sällan stora skräddarsydda plattformar själva, men är ofta mottagare av programvara som beställts eller föreskrivits av en statlig finansiär – en rapporteringsportal, ett ärendehanteringssystem som ett bidrag eller ett avtal kräver att de använder – med litet inflytande över dess design, dess tekniska skuld eller dess leverantör. En organisation i social sektor som är beroende av ett statligt föreskrivet system ärver systemets felmönster utan att ärva något av den hävstång som behövs för att rätta till dem, vilket är ytterligare ett skäl till att utfallsbaserade finansieringsrelationer måste ta hänsyn till den operativa bördan av föreskriven teknik (se Ämne 3.7 — Offentlig upphandling och beställning), inte bara själva utfallsmåttet.

Multilaterala och internationella organ

Multilaterala organ och utvecklingsorgan främjar alltmer programvara byggd för ett lands offentliga förvaltning som ett återanvändbart digitalt allmängods andra länder kan anpassa, i stället för att varje regering beställer ett motsvarande system av en privat leverantör till full kostnad. Den särskilda risken här är att ett digitalt allmängods byggt för ett lands rättsliga och administrativa sammanhang kan antas på annat håll med för liten anpassning och därmed importera antaganden – om identitet, behörighet eller process – som inte faktiskt överförs; löftet om delad, öppen infrastruktur är verkligt, men bara där genuin lokal anpassningskapacitet följer med koden.

Vanliga felmönster

Big-bang-övergången som fallerar vid driftstart. Ett kritiskt äldre system ersätts i en enda, oåterkallelig övergång efter år av utveckling utan någon levande produktionsexponering, och ett fel som bara visar sig i verklig skala eller i ett gränsfall ingen prövade dyker upp första dagen av full drift, utan väg att gå tillbaka till det gamla systemet eftersom det redan har avvecklats. Kostnaden mäts i uteblivna utbetalningar, nekade tjänster eller avbrott som drabbar just de medborgare systemet finns för att tjäna, i värsta tänkbara ögonblick – det ögonblick då alla förlitade sig på att ersättningen fungerade.

Tyst ackumulering av teknisk skuld. Deadlinetryck vinner upprepade gånger över den tid som behövs för att rätta kända genvägar, och varje uppskjutande är var för sig försvarbart, tills den ackumulerade skulden gör även en liten ändring oproportionerligt dyr och riskabel. Kostnaden visar sig år senare som ett system ingen säkert kan ändra, en arbetsstyrka som i det tysta har slutat försöka något utöver de mest brådskande lapparna och ett slutligt moderniseringsprogram långt större och dyrare än kontinuerlig, mindre förnyelse hade varit.

Leverantörsberoende som misstas för stabilitet. Ett offentligt organ förnyar upprepade gånger samma leverantörs avtal eftersom ett byte ser för störande ut att försöka, utan att någonsin pröva vad verkliga bytekostnader skulle vara eller förhandla om det kodägande och de öppna dataformat som skulle hålla dessa kostnader hanterbara. Kostnaden är en bestående försvagad förhandlingsposition i fråga om pris och villkor, som upptäcks först när leverantörens servicekvalitet sjunker eller dess priser stiger och det offentliga organet finner att det saknar ett trovärdigt alternativ.

Kosmetisk agilitet. Ett leveransteam antar agila ceremonier – dagliga möten, sprintar, en backlogg – medan den underliggande avtals-, finansierings- och styrningsstrukturen fortfarande förutsätter en fast specifikation och en enda go/no-go-milstolpe, så att teamet rapporterar sprinthastighet medan det i själva verket levererar mot en vattenfallsplan under ytan. Kostnaden är att ingen av agilitetens genuina fördelar – tidig användarrespons som ändrar riktning, risk som syns tidigt – förverkligas, medan skenet av modern praxis gör den underliggande stelheten svårare för tillsynsorgan att se och utmana.

Policy om öppen källkod utan underhållsplan. Ett offentligt organ publicerar källkod för att uppfylla en policy om öppen källkod som standard men behandlar utgivningen som ett engångssteg för efterlevnad, utan resurser för att granska externa bidrag, patcha sårbarheter eller underhålla dokumentation. Kostnaden är ett publicerat förråd som ser öppet ut men fungerar som en övergiven återvändsgränd, vilket skadar förtroendet för hela programmet för öppen källkod som standard mer än att aldrig ha publicerat alls hade gjort.

Mognadsmodell

Checklista

• Inventera teknisk skuld för varje kritiskt system och granska registret enligt en fast cykel.
• Tillämpa ett dokumenterat ramverk för bygga eller köpa innan du förbinder dig till någon betydande ny programvara.
• För varje ersättning av ett äldre system, välj inkrementell migrering som standard och kräv ett uttryckligt skäl för en big-bang-övergång.
• Bekräfta villkor för källkodsägande eller deposition i varje programvaruavtal före undertecknande.
• Publicera källkod under en policy om öppen källkod som standard, med en dokumenterad undantagsprocess.
• Avsätt resurser för löpande underhåll av varje förråd som publiceras under den policyn, inte bara dess första utgivning.
• Kräv öppna, dokumenterade dataformat även där den underliggande programvaran är proprietär.
• Strukturera finansieringsportar kring demonstrerad fungerande programvara i stället för en enda milstolpe med fast specifikation.
• Bygg och pröva en minsta livskraftig produkt med verkliga användare innan du förbinder dig till full omfattning.
• Följ driftsättningsfrekvens, felfrekvens och utestående teknisk skuld som stående styrningsindikatorer.
• Bedöm ingenjörskapaciteten i egen regi mot vad som behövs för att vara en kunnig köpare, och åtgärda identifierade luckor.
• Prioritera infrastruktur som inte längre stöds och odokumenterade integrationer före kosmetisk modernisering.

Viktiga källor

• GOV.UK Service Standard, Government Digital Service, Storbritannien — en nationell standard för digitala tjänster som kräver iterativ, användarcentrerad leverans och öppna standarder för offentliga tjänster.
• Office of Management and Budget, Federal Source Code Policy (M-16-21), USA — den federala policy som kräver att myndigheter överväger återanvändning och utgivning som öppen källkod av skräddarsydd statlig programvara.
• Free Software Foundation Europe, kampanjen Public Money, Public Code — motiveringen, utvecklad för en europeisk publik, för att släppa offentligt finansierad programvaras källkod under licenser för fri programvara och öppen källkod.
• Ward Cunningham, ”The WyCash Portfolio Management System” (OOPSLA 1992, erfarenhetsrapport) — det ursprungliga uttalandet av metaforen om teknisk skuld.
• Digital Public Goods Alliance — ett initiativ med många intressenter som upprätthåller standarder och ett register för öppen programvara, öppna data och öppet innehåll utformat för att tjäna offentliga utvecklingsmål.

Referenser

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/