Softwareudvikling og platforme i den offentlige sektor

Hvorfor det er vigtigt for offentlig værdi

Næsten enhver offentlig tjeneste, en borger berører i dag – registrering af en fødsel, ansøgning om en ydelse, betaling af en skatteregning, booking af en retsdato – kører på software et sted bag skranken eller skærmen. Den software er sjældent et engangskøb; den bliver en del af statens permanente infrastruktur, ofte længere levende end den administration, der bestilte den, den leverandør, der byggede den, og det programmeringssprog, dens udviklere blev uddannet i. Et offentligt organ oplever ikke software, som det oplever en bygning eller en vej, hvor aktivets tilstand er synlig; software forfalder usynligt, og regningen for det forfald ankommer år senere som en nødsituation.

Den spænding, der driver dette emne, er strukturel. Software er i sig selv iterativ – krav bliver klarere, når brugere interagerer med et fungerende system, og den bedste ingeniørpraksis er at bygge noget småt, lære og tilpasse. Offentlige indkøbs- og ansvarlighedscyklusser (se Emne 3.7 — Offentlige indkøb og kommissionering) var derimod bygget til anlægsarbejder og forsvarskontrakter: en fast specifikation, ét stort tilslag, milepælsbetalinger og en business case godkendt år før leveringen begynder. Når en lovgivende forsamling eller en revisor forventer en fastpris-, fastomfangs-kontrakt, og et udviklingsteam har brug for at skifte kurs efter den første udgivelse, viser misforholdet sig som scope creep, budgetoverskridelse eller et system, der var korrekt specificeret i 2019 og forældet, når det leveres.

De platforme, dette emnes ingeniørpraksis findes for at bygge – fælles identitetssystemer, betalingsinfrastruktur, sagsbehandlingsværktøjer genbrugt på tværs af ministerier – er genstand for Emne 5.1 (se Emne 5.1 — Digital forvaltning og digital transformation); dette emne handler om disciplinen at bygge og købe den software, der gør enhver sådan platform, eller enhver enkelt tjeneste, pålidelig, udskiftelig og ejet af det offentlige organ, der afhænger af den, frem for af den leverandør, der tilfældigvis skrev den først.

Kernebegreber

Bygge-eller-købe-beslutningen er valget mellem at bestille skræddersyet software skrevet til én organisations behov og at vedtage konfigurerbar standardsoftware, der allerede er bygget til et marked af lignende købere. At købe er normalt billigere og mindre risikabelt til et behov, der ikke er ægte særegent – løn, e-mail, standard sagsbehandling – mens bygning kun er berettiget, hvor kravet er forskelligt nok til, at intet konfigurerbart produkt passer, eller hvor kapaciteten selv er et strategisk aktiv, organisationen har brug for at eje og udvikle.

Teknisk gæld er en metafor, opfundet af softwareingeniøren Ward Cunningham i 1992, for de akkumulerede omkostninger ved at vælge en hensigtsmæssig måde at udgive software på nu frem for en grundigere måde, der ville have taget længere tid. Teknisk gæld er, som finansiel gæld, ikke i sig selv forkert at optage – Cunninghams eget pointe var, at udgive fungerende kode hurtigt og refaktorere bagefter kan være det rigtige valg – men gæld, der aldrig tilbagebetales, påløber renter som langsommere levering, flere fejl og stigende risiko, og et offentligt organ, der ikke kan se sin gæld, kan ikke beslutte, om det vil afvikle den eller lade den vokse.

Et legacy-system er en gammel teknologi, applikation eller platform, der forbliver i aktiv brug trods at være forældet, ofte fordi udskiftning er dyr, eller fordi ingen tilbage i organisationen fuldt ud forstår, hvad den gør. Legacy-systemer er særligt vedholdende i det offentlige: centrale skatte-, ydelses- og socialforsikringssystemer skrevet for årtier siden i sprog som COBOL – Common Business-Oriented Language, designet i 1960 til administrativ databehandling – behandler stadig transaktioner for millioner af borgere, fordi systemerne virker, og den institutionelle viden, der skal til for sikkert at pensionere dem, ofte selv er gået på pension først.

Softwaremodernisering er den generelle betegnelse for at konvertere, omskrive eller migrere et legacy-system til en aktuel arkitektur, et aktuelt sprog eller en aktuel platform. Softwaremodernisering spænder fra en fuld omskrivning til mere konservative muligheder som at re-hoste den samme kode på moderne infrastruktur, og valget mellem dem er lige så meget en risikostyringsbeslutning som en teknisk.

Strangler fig-mønstret er en inkrementel moderniseringstilgang, opkaldt efter en slyngplante, der vokser omkring et værtstræ og gradvist erstatter det, hvor ny funktionalitet bygges ved siden af et legacy-system, og trafik omdirigeres til den stykke for stykke, frem for at erstatte hele systemet i ét omskifte. Strangler fig-mønstret betyder noget, fordi det lader hvert trin blive testet, rullet tilbage eller sat på pause uden at tage hele tjenesten ned – det modsatte af en big bang-udskiftning, hvor det gamle system slukkes og det nye tændes i ét øjeblik uden vej tilbage, hvis noget er galt.

Leverandørlåsning opstår, når en kunde bliver så afhængig af én leverandørs proprietære teknologi, dataformater eller kontraktvilkår, at skift til en anden leverandør medfører uoverkommelige omkostninger eller risiko. Leverandørlåsning er en særlig fare i offentlig software, fordi køberen er en tilbagevendende kunde med begrænset praktisk evne til at gå væk fra et system, der kører en kritisk tjeneste, hvilket svækker dens forhandlingsposition ved hver efterfølgende fornyelse.

Fri og open source-software er software distribueret under en licens, der giver brugere friheden til at bruge, studere, ændre og videredistribuere kildekoden. Fri og open source-software ligger til grund for en open source som standard-politik, hvorunder et offentligt organ som standard offentliggør den kildekode, det bestiller, medmindre en specifik grund – sikkerhedsfølsomhed, tredjepartsrettigheder – berettiger tilbageholdelse; begrundelsen opsummeres normalt som «offentlige penge, offentlig kode»: software betalt én gang med offentlige midler bør ikke skulle betales igen, i en anden jurisdiktion, af et andet offentligt organ, der løser det samme problem.

Et digitalt kollektivt gode er åben software, åbne data eller åbent indhold udgivet under en åben licens, designet til at hjælpe med at opfylde et offentligt udviklings- eller styringsformål frem for at generere et kommercielt afkast. Digitale kollektive goder omrammer én regerings open source-udgivelse som en del af en bredere, fælles infrastruktur, andre regeringer og civilsamfundsorganisationer kan trække direkte på, ikke blot en intern gennemsigtighedsgestus.

Agil softwareudvikling er en paraplybetegnelse for iterative tilgange til at bygge software, der foretrækker fungerende software, hyppig levering og at reagere på forandring frem for at følge en fast plan aftalt på forhånd. Agil softwareudvikling står i kontrast til vandfaldsmodellen, en sekventiel tilgang, hvor krav, design, bygning og test hver færdiggøres fuldt, før den næste begynder; vandfaldets tiltrækning for offentlige organer har altid været, at dets milepæle kortlægges pænt på en fastpriskontrakt og en årlig budgetcyklus, hvorfor så megen indkøbslovgivning stadig antager den, selv hvor leveringen reelt er agil.

Et minimum levedygtigt produkt er den mindste version af en tjeneste, der kan udgives til rigtige brugere for at teste, om den virker, og lære hvad der skal bygges næste gang. Konceptet minimum levedygtigt produkt, tilpasset i offentlige digitale servicehåndbøger, giver et iterativt team en forsvarlig måde at vise en finansieringsgiver eller en revisor noget reelt og fungerende længe før det fulde omfang er færdigt – forudsat at ansvarlighedsprocessen accepterer en ægte minimal udgivelse frem for at behandle den som det færdige produkt under et andet navn.

Bedste praksis

1. Køb som standard til udifferentierede behov, og forbehold bygning til det, der er ægte særegent. Løn, e-mail og generelle sagsbehandlingsbehov er sjældent forskellige nok fra enhver anden organisations til at retfærdiggøre skræddersyet software; byg kun, hvor kravet, skalaen eller behovet for at eje og udvikle kapaciteten over årtier er ægte anderledes end det, markedet tilbyder.
2. Gør teknisk gæld synlig, før du beslutter, hvor meget du vil bære. Vedligehold et register over kendte genveje, udskudte rettelser og ustøttede afhængigheder for hvert system i drift, gennemgået efter en fast cyklus, så det at bære gæld et år mere er en bevidst afvejning frem for at ingen kiggede.
3. Planlæg aldrig et enkelt, uigenkaldeligt omskifte som den eneste vej væk fra et kritisk legacy-system. Foretræk inkrementelle tilgange som strangler fig-mønstret, der lader hvert stykke blive testet, omvendt og udrullet gradvist; en big bang-udskiftning af et system, millioner afhænger af, koncentrerer års risiko i én enkelt weekend uden vej tilbage, hvis noget svigter.
4. Behandl den kildekode, din organisation betaler for at få skrevet, som et aktiv, den ejer, ikke en tjeneste, den lejer. Forhandl kildekodeescrow eller direkte ejerskab på kontrahentstidspunktet, ikke efter en tvist er begyndt, da en leverandør, der besidder den eneste kopi af din kritiske tjenestes kode, er leverandørlåsning ved design.
5. Offentliggør kildekode som åben som standard og kræv en specifik begrundelse for at tilbageholde den. En open source som standard-politik, anvendt konsekvent, forvandler hver afdelings skræddersyede software til et fælles tværoffentligt aktiv frem for en engangsomkostning og lader eksterne eksperter finde sikkerhedsfejl, et internt team alene ville overse.
6. Skriv softwarekontrakter, der gør iterativ levering lovlig, ikke blot teknisk mulig. En kontrakt, der kun betaler mod en fast specifikation aftalt ved underskrift, tvinger et team til at vælge mellem ærlig agil praksis og kontraktlig overholdelse; brug i stedet trinvise finansieringsporte knyttet til demonstreret fungerende software frem for én milepæl til sidst.
7. Finansiér modernisering som et løbende program, ikke et engangsanlægsprojekt. Et legacy-system moderniseret én gang og derefter efterladt i yderligere tyve år akkumulerer den samme risiko, det startede med; budgetter til kontinuerlig, inkrementel fornyelse, som en vejmyndighed budgetterer til genbelægning, ikke en storslået udskiftning én gang pr. generation.
8. Vælg åbne standarder og portable dataformater, selv når du køber kommerciel software. At kræve, at en leverandørs system gemmer og eksporterer data i åbne, dokumenterede formater, holder skifteomkostninger lave, selv hvor softwaren selv er proprietær, og er ofte et mere opnåeligt nærtidigt værn mod låsning end at insistere på, at hvert system er open source.
9. Byg et minimum levedygtigt produkt og vis det til rigtige brugere, før du forpligter dig til fuldt omfang. At udgive en ægte minimal version og derefter iterere på det lærte fanger forkerte antagelser, mens de stadig er billige at rette, frem for efter et fuldskalasystem er bygget mod dem.
10. Hold intern ingeniørkapacitet tilstrækkelig til at være en intelligent køber, selv hvor leveringen er outsourcet. Et offentligt organ, der har udhulet sin tekniske ekspertise, kan ikke vurdere en leverandørs forslag, få øje på tidlige advarselstegn på et trængt projekt eller forhandle sig ud af låsning, uanset hvad dets indkøbsregler siger på papiret.
11. Afvikl et legacy-systems risikoprofil før dets brugerflade. Prioritér at erstatte ustøttede sprog, upatchet infrastruktur og udokumenterede integrationer – de svigt, der forårsager nedbrud og brud – før visuel modernisering, der bærer langt mindre driftsrisiko.
12. Mål leveringssundhed med ingeniørindikatorer, ikke kun budget- og tidsplansafvigelse. Udrulningsfrekvens, fejlrater og alderen på det ældste uadresserede tekniske gældspunkt fortæller en styringsbestyrelse mere om, hvorvidt et program vil lykkes, end om det i øjeblikket er inden for budget, ofte den sidste indikator, der bevæger sig.

Spørgsmål at drøfte med dit team

Ved vi faktisk, hvor megen teknisk gæld vi bærer, system for system? De fleste offentlige organer kan oplyse deres anlægsbudget for året, men kan ikke med nogen sikkerhed oplyse, hvor meget af deres softwarelandskab der kører på ustøttede komponenter, udokumenteret logik eller kode, ingen tilbageværende medarbejder fuldt forstår. Brug dette spørgsmål til at bede hver systemejer i rummet om ærligt at vurdere, hvor sikre de er på, at deres team sikkert kunne ændre deres mest kritiske system uden at ødelægge noget, ingen forudså. Drøft, hvad der skal til for at omsætte disse vurderinger til et egentligt register, gennemgået efter en fast cyklus, frem for stiltiende viden, der forlader organisationen, når en nøgleudvikler gør. Overvej også, hvem der i øjeblikket beslutter, hvor megen gæld der er acceptabel at bære, og om den beslutning er bevidst eller sker som standard.

Hvis vores mest kritiske legacy-system skulle udskiftes fra i dag, ville vi så planlægge et big bang-omskifte eller en inkrementel migration – og hvorfor? Instinktet til at udskifte et gammelt system på én gang er ofte drevet af budgetcyklusser og programledelsesbekvemmelighed frem for teknisk nødvendighed, og det koncentrerer enorm risiko i ét enkelt øjeblik. Brug dette spørgsmål til at gennemgå, konkret, hvordan en strangler fig-agtig inkrementel migration af jeres mest kritiske legacy-system faktisk ville se ud, stykke for stykke. Drøft, hvad der i dag forhindrer jer i at vælge den vej – finansiering struktureret omkring én go-live-dato, en styringsproces der vil have én ren milepæl, eller en reel teknisk begrænsning, der gør inkrementel migration umulig for dette system.

Hvem ejer faktisk kildekoden til den software, vores organisation har betalt for at få bygget, og kunne vi bevise det? Mange offentlige organer opdager først, når et forhold til en leverandør bliver surt, at kontrakten aldrig sikrede klart ejerskab eller escrow af den kode, deres kritiske tjenester afhænger af. Brug dette spørgsmål til at hive kontrakterne for jeres tre vigtigste skræddersyede systemer frem og tjekke, specifikt, hvad hver siger om kodeejerskab, escrow og retten til at tage koden med til en anden leverandør. Drøft, hvad der ville ske i morgen, hvis jeres primære leverandør af nogen af de tre systemer gik konkurs eller nægtede at fortsætte forholdet.

Hvor falder vi tilbage på lukket, proprietær software af vane, når en open source som standard-tilgang ville tjene os lige så godt eller bedre? Open source som standard-politikker findes netop fordi de fleste offentlige organer løser overlappende problemer uafhængigt, hver betalende den fulde pris for software, et andet offentligt organ allerede har bygget og kunne have delt. Brug dette spørgsmål til at identificere ét system, der i øjeblikket bygges eller specificeres, og spørg, om en tilsvarende allerede findes som open source-software andetsteds i det offentlige, eller om det, I bygger, nyttigt kunne udgives, så andre kan genbruge det. Drøft, hvilken specifik barriere – sikkerhedsbekymring, indkøbsvane, manglende klar politik – der faktisk forhindrer genbruget, frem for at antage, at det ikke er relevant her.

Tillader vores indkøbs- og ansvarlighedsproces faktisk ærlig agil levering, eller omdøber den blot vandfaldsmilepæle til sprints? Det er almindeligt, at et team kører nominelt agile ceremonier, mens det stadig finansieres, styres og rapporteres mod en fast specifikation aftalt ved kontraktunderskrift, hvilket genskaber alle vandfaldets svigttilstande under en agil etiket. Brug dette spørgsmål til at spore ét levende digitalt program fra dets business case gennem dets nuværende styringsrapportering og spørg, om finansieringsstrukturen ville tolerere, at programmet skiftede retning baseret på, hvad en ægte tidlig udgivelse lærte det. Drøft, hvad der skulle ændre sig i, hvordan programmet finansieres og rapporteres, for at iterativ levering er reel frem for kosmetisk (se Emne 3.7 — Offentlige indkøb og kommissionering).

Har vi nok intern ingeniørkapacitet til at være en intelligent køber af de systemer, vi afhænger mest af? En organisation, der har outsourcet al sin tekniske dømmekraft, ikke blot sin leveringskapacitet, kan ikke se, om en leverandørs forslag er forsvarligt, om et projekt stille bevæger sig mod problemer, eller hvad en rimelig pris for arbejdet faktisk er. Brug dette spørgsmål til at spørge, hvor mange personer i jeres organisation der troværdigt kunne gennemgå et teknisk arkitekturforslag til jeres vigtigste system, og hvordan det tal har ændret sig over de sidste fem år. Drøft, hvad der skal til for at genopbygge den kapacitet, hvor den er eroderet, og hvad jeres organisation mister, i forhandlingsposition såvel som leveringsrisiko, for hvert år den går uden.

I praksis: et eksempel på offentlig værdi

En fiktiv regional regering – kun illustrativ, ikke en beskrivelse af nogen reel jurisdiktion – kørte sine dagpengeansøgninger gennem et system, første gang skrevet for mere end tredive år siden, vedligeholdt af et skrumpende antal udviklere, der forstod dets oprindelige programmeringssprog. Ansøgningsvolumen var vokset langt ud over, hvad systemets designere havde forudset, natlige behandlingskørsler nåede i stigende grad ikke at blive færdige, før morgenens transaktioner begyndte, og myndighedens teknologiledelse advarede om, at et uplanlagt nedbrud, der berørte ydelsesudbetalinger, nu var et spørgsmål om hvornår, ikke om.

Myndighedens første instinkt var et konventionelt svar på et problem, der føltes presserende: bestil en enkelt stor kontrakt til at erstatte hele systemet med en moderne platform, fuldt specificeret på forhånd, leveret mod en fast toårig tidsplan med ét omskiftningsweekend til sidst. En forhåndsimplementeringsgennemgang bestilt af myndighedens revisionsudvalg rejste et hårdt spørgsmål, før kontrakten blev underskrevet: hvad ville der ske med ydelsesudbetalinger til flere hundrede tusinde ansøgere, hvis det nye system havde en uopdaget fejl i sin første uge med fuldskala, live drift, med det gamle system allerede nedlagt og ingen vej tilbage.

Myndigheden skiftede kurs. Den beholdt legacy-systemet kørende som registreringssystem og begyndte at bygge ny funktionalitet til ansøgningsmodtagelse og berettigelsesvurdering ved siden af det, ved hjælp af en strangler fig-tilgang: hvert nyt modul blev først udgivet til en lille procentdel af nye ansøgninger, verificeret mod det gamle systems parallelle output og udvidet først, når dets resultater matchede. Inden for atten måneder kørte flertallet af nye ansøgninger gennem moderne komponenter, mens det oprindelige system håndterede en skrumpende restsagsmængde, med mulighed for at dirigere en enkelt sag tilbage til den gamle vej, hvis noget så forkert ud. Myndigheden krævede også, i hver ny kontrakt udstedt til dette arbejde, at kildekoden blev ejet af myndigheden og offentliggjort som open source, når sikkerhedsgennemgangen var færdig, så andre regionale regeringer, der stod over for det samme problem med ældende mainframes, kunne tilpasse komponenterne frem for at gentage den samme bygning fra bunden.

Den fulde udskiftning af legacy-systemets sidste restfunktioner tog næsten fire år – længere, på papiret, end den oprindelige toårige big bang-plan lovede. Men ingen ansøger oplevede nogensinde et uplanlagt nedbrud under overgangen, hvert trin var lille nok til at blive rullet tilbage inden for timer, når en fejl blev fundet, og to nabo-regionale regeringer begyndte at tilpasse myndighedens offentliggjorte berettigelsesvurderingskode til deres egne systemer inden for det første år af dens udgivelse.

Fire sektorlinser

Lokal forvaltning

Lokal forvaltning kører typisk et stort antal mindre, afkoblede systemer frem for en håndfuld platforme i national skala, hvilket betyder, at teknisk gæld akkumuleres på tværs af mange separat indkøbte, separat vedligeholdte applikationer frem for i ét synligt flagskibssystem. Lokale myndigheder har normalt den mindste interne ingeniørkapacitet af nogen forvaltningsniveau, hvilket gør argumentet for at købe konfigurerbar standardsoftware frem for skræddersyede bygninger særligt stærkt og gør fælles regionale eller nationale platforme – genstand for Emne 5.1 (se Emne 5.1 — Digital forvaltning og digital transformation) – til en særlig værdifuld vej til at undgå, at hver myndighed separat genopbygger den samme kapacitet.

National forvaltning

National forvaltning er, hvor de ældste og mest konsekvensfulde legacy-systemer har tendens til at sidde – central skatte-, socialforsikrings- og ydelsesadministration – fordi disse ofte var blandt de første store edb-indsatser i det offentlige og nu bærer den højeste indsats for ethvert moderniseringssvigt. National forvaltning har typisk den specialiserede kommercielle og tekniske kapacitet til at køre et ægte inkrementelt moderniseringsprogram og til at forhandle reelt kodeejerskab ind i sine kontrakter, og det er normalt det forvaltningsniveau, der er bedst placeret til at fastsætte en open source som standard-politik med nok skala bag sig til at få tværoffentligt genbrug til faktisk at ske.

Den sociale sektor og nonprofit

Nonprofitorganisationer og velgørende organisationer bygger sjældent selv store skræddersyede platforme, men er hyppigt på den modtagende ende af software bestilt eller påbudt af en offentlig finansieringsgiver – en rapporteringsportal, et sagsbehandlingssystem, en bevilling eller kontrakt kræver, de bruger – med lille indflydelse på dets design, dets tekniske gæld eller dets leverandør. En social-sektor-organisation, der afhænger af et regeringspåbudt system, arver dette systems svigttilstande uden at arve nogen af løftestængerne til at rette dem, hvilket er en grund mere til, at resultatbaserede finansieringsforhold må tage højde for den driftsmæssige byrde af påbudt teknologi (se Emne 3.7 — Offentlige indkøb og kommissionering), ikke kun selve resultatmålet.

Multilateral og international

Multilaterale organer og udviklingsmyndigheder fremmer i stigende grad software bygget til ét lands offentlige forvaltning som et genbrugeligt digitalt kollektivt gode, andre lande kan tilpasse, frem for at hver regering bestiller et tilsvarende system fra en privat leverandør til fuld pris. Den særlige risiko her er, at et digitalt kollektivt gode bygget til ét lands juridiske og administrative kontekst kan vedtages andetsteds med for lidt tilpasning og importere antagelser – om identitet, berettigelse eller proces – der faktisk ikke overføres; løftet om fælles, åben infrastruktur er reelt, men kun hvor ægte lokal tilpasningskapacitet følger med koden.

Almindelige fejlmønstre

Big bang-omskiftet, der svigter ved go-live. Et kritisk legacy-system erstattes i ét enkelt, uigenkaldeligt omskifte efter års udvikling uden live produktionseksponering, og en fejl, der kun viser sig i reel skala eller i et kanttilfælde, ingen testede, dukker op den første dag med fuld drift, uden vej tilbage til det gamle system, fordi det allerede er nedlagt. Omkostningen måles i udeblevne udbetalinger, afviste tjenester eller nedbrud, der berører netop de borgere, systemet findes for at tjene, på det værst mulige tidspunkt – det øjeblik alle stolede på, at udskiftningen virkede.

Stille ophobning af teknisk gæld. Deadlinepres vinder gentagne gange argumentet mod den tid, der skal til for at rette kendte genveje, og hver udskydelse er individuelt forsvarlig, indtil den akkumulerede gæld gør selv en lille ændring uforholdsmæssigt dyr og risikabel. Omkostningen viser sig år senere som et system, ingen sikkert kan ændre, en arbejdsstyrke der stille har holdt op med at forsøge andet end de mest presserende rettelser, og et eventuelt moderniseringsprogram langt større og dyrere, end kontinuerlig, mindre fornyelse ville have været.

Leverandørlåsning forvekslet med stabilitet. Et offentligt organ fornyer den samme leverandørs kontrakt gentagne gange, fordi skift ser for forstyrrende ud at forsøge, uden nogensinde at teste, hvad ægte skifteomkostninger ville være, eller forhandle om det kodeejerskab og de åbne dataformater, der ville holde disse omkostninger håndterbare. Omkostningen er en permanent svækket forhandlingsposition på pris og vilkår, opdaget først når leverandørens servicekvalitet falder eller dens priser stiger, og det offentlige organ finder, at det ikke har noget troværdigt alternativ.

Kosmetisk agil. Et leveringsteam vedtager agile ceremonier – stand-ups, sprints, en backlog – mens den underliggende kontrakt, finansiering og styringsstruktur stadig antager en fast specifikation og én enkelt go/no-go-milepæl, så teamet rapporterer sprinthastighed, mens det faktisk leverer mod en vandfaldsplan nedenunder. Omkostningen er, at ingen af agiles ægte fordele – tidlig brugerfeedback der ændrer retning, risiko der afdækkes tidligt – materialiseres, mens skinnet af moderne praksis gør den underliggende rigiditet sværere for tilsynsorganer at se og udfordre.

Open source-politik uden en vedligeholdelsesplan. Et offentligt organ offentliggør kildekode for at opfylde en open source som standard-politik, men behandler udgivelsen som et engangs overholdelsestrin, uden ressourcer til at gennemgå eksterne bidrag, patche sårbarheder eller vedligeholde dokumentation. Omkostningen er et offentliggjort repository, der ser åbent ud men fungerer som en uvedligeholdt blindgyde, hvilket skader tilliden til det bredere open source som standard-program mere, end aldrig at offentliggøre ville have gjort.

Modenhedsmodel

Tjekliste

• Opgør hvert kritisk systems tekniske gæld og gennemgå registeret efter en fast cyklus.
• Anvend et dokumenteret bygge-eller-købe-rammeværk, før der forpligtes til nogen væsentlig ny software.
• For enhver udskiftning af et legacy-system: vælg inkrementel migrationsmetode som standard og kræv en eksplicit begrundelse for et big bang-omskifte.
• Bekræft vilkår for kildekodeejerskab eller escrow i hver softwarekontrakt før underskrift.
• Offentliggør kildekode under en open source som standard-politik, med en dokumenteret undtagelsesproces.
• Ressourcesæt løbende vedligeholdelse for hvert repository offentliggjort under den politik, ikke kun dets første udgivelse.
• Kræv åbne, dokumenterede dataformater, selv hvor den underliggende software er proprietær.
• Strukturér finansieringsporte omkring demonstreret fungerende software frem for en enkelt fast-specifikations-milepæl.
• Byg og test et minimum levedygtigt produkt med rigtige brugere, før der forpligtes til fuldt omfang.
• Følg udrulningsfrekvens, fejlrater og udestående teknisk gæld som stående styringsindikatorer.
• Vurdér intern ingeniørkapacitet mod det, der skal til for at være en intelligent køber, og luk identificerede huller.
• Prioritér ustøttet infrastruktur og udokumenterede integrationer før kosmetisk modernisering.

Centrale kilder

• GOV.UK Service Standard, Government Digital Service, Det Forenede Kongerige – en national digital servicestandard, der kræver iterativ, brugercentreret levering og åbne standarder for offentlige tjenester.
• Office of Management and Budget, Federal Source Code Policy (M-16-21), USA – den føderale politik, der kræver, at myndigheder overvejer genbrug og open source-udgivelse for specialudviklet offentlig software.
• Free Software Foundation Europe, Public Money, Public Code-kampagnen – begrundelsen, udviklet til et europæisk publikum, for at udgive offentligt finansieret softwares kildekode under frie og open source-licenser.
• Ward Cunningham, «The WyCash Portfolio Management System» (OOPSLA 1992-erfaringsrapport) – den oprindelige formulering af teknisk gæld-metaforen.
• Digital Public Goods Alliance – et initiativ med flere interessenter, der vedligeholder standarder og et register for åben software, åbne data og åbent indhold designet til at tjene offentlige udviklingsmål.

Henvisninger

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/