Sådan skelner du mellem kravtyper i softwarevalg

Hvorfor kravtyper er et valgværktøj – ikke en teknologidiskussion

Digitaliseringsstyrelsens vejledning om open source i den offentlige sektor slår fast, at open source ikke er et spørgsmål om it-afdelingens teknologiske præferencer. Det er en strategisk forretningsmodel og nogle udviklingsmetoder, der styrker offentlige myndigheders medejerskab til løsningerne og muligheden for at dele, videreudvikle og genbruge digitale løsninger.

Vejledningen understreger, at valget mellem open source og proprietære løsninger ikke er enten-eller. Det handler om at vælge den løsning, der skaber værdi ud fra den enkelte myndigheds udfordringer og behov.

Kravtyper omsætter dette udgangspunkt til praksis. Opdeler man kravene i kategorier – sagsbehandling og dokumentation, arkitektur og integration, licens og vedligeholdelse, sikkerhed og databeskyttelse, organisation og kompetencer, økonomi over livscyklussen samt afhængighed og genbrug – bliver det tydeligt, hvor de to forretningsmodeller svarer forskelligt. Rapporten om open source i det offentlige peger på, at forskellen bl.a. ligger i kontrol over kildekode, licensvilkår og vedligeholdelse.

Kravtyperne skal kunne læses af flere fagligheder i beslutningsprocessen. Vejledningens målgruppe er it-projektledere, it-jurister, it-arkitekter, indkøbere, contract managers samt it-chefer og andre strategiske beslutningstagere i offentlige myndigheder, der skal tage stilling til softwareanskaffelser.

Derfor bør hver kravtype have en navngiven ejer, før tilbuddene vurderes: forvaltningsretlige krav hører til sagsbehandlingen, licens- og vedligeholdelseskrav til kontraktmiljøet, og arkitektur- og integrationskrav til den tekniske arkitekturfunktion.

Fra behov til krav: Formål, opgave og kontekst først

Digitaliseringsstyrelsen konstaterer, at forudsætningerne for at bruge open source-software i den offentlige sektor varierer betydeligt og afhænger af både softwaretype og formål. Kravtyperne kan derfor ikke fastlægges generelt: Et sagsbehandlingssystem, et tekstbehandlingsværktøj og et AI-værktøj udløser forskellige kravprofiler til eksempelvis dokumentation, integration og drift.

For ny lovgivning gælder en obligatorisk rækkefølge, der også styrer it-kravene. Fagministerier skal vurdere og beskrive lovforslagets offentlige implementeringskonsekvenser i hele beslutningskæden.

Konsekvenserne omfatter organisatoriske forhold, omstillings- og driftskonsekvenser, it-understøttelse, it-styring og risiko, databeskyttelse samt betydning for borgeren. Har lovforslaget offentlige implementeringskonsekvenser, skal det sendes i præhøring hos sekretariatet for digitaliseringsklar lovgivning senest seks uger før offentlig høring.

Generativ AI viser, hvorfor softwaretypen skal afklares først. Digitaliseringsstyrelsens guide til myndigheder beskriver, at generative AI-værktøjer bygger på grundmodeller, der ofte er trænet på både tekst, billede, lyd og video.

Nogle grundmodeller og generative AI-værktøjer er open source og kan derfor downloades og afvikles på egne servere. Om løsningen kører som cloudtjeneste eller på egne servere, er et selvstændigt krav, der skal stilles uafhængigt af, om softwaren er open source eller proprietær.

Konteksten fastlægger detaljeringsgraden. Ombudsmanden fremhæver, at indførelse af digitale processer kræver planlægning, og at dårlig forberedelse kan føre til fejl og mangler i it-systemerne. Kravspecifikationen bør derfor beskrive sagsforløbene – ikke kun funktionerne.

Proces til udvikling af kravspecifikation i softwarevalg

Sagsbehandlings- og dokumentationskrav

Ombudsmanden præciserer, at de generelle forvaltningsretlige regler og principper gælder, uanset om sagsbehandlingen foregår manuelt eller digitalt. Kravene til myndighedernes sagsbehandling gælder i lige så høj grad, når sagsbehandlingen digitaliseres og automatiseres.

De retter sig mod offentlige it-systemer, herunder sagsstyringssystemer og selvbetjeningsløsninger. Ansvaret for, at kravene efterleves, ligger hos den enkelte myndighed.

De konkrete krav kan omsættes direkte til acceptkriterier: It-systemet skal understøtte og sikre journalisering og dokumentation af relevante sagsakter og sikre et afsendt brevs integritet og autenticitet, herunder entydig identifikation af afsenderen.

Kravene skal formuleres ud fra de forløb, sagerne kan tænkes at få. En forsvarlig tilrettelæggelse forudsætter nemlig, at både formelle og materielle krav indtænkes fra begyndelsen.

Konsekvenserne af at springe dette over er dokumenterede. Ombudsmanden har i de senere år i en del sager konstateret, at offentlige it-løsninger ikke har sikret overholdelse af de forvaltningsretlige krav.

Fejl i et it-system rammer typisk ikke kun én borger – skadevirkningerne mangedobles, fordi manglerne slår systematisk igennem, indtil de bliver udbedret. Når et mangelfuldt it-system først er sat i drift, kan det være både svært og dyrt at rette op på.

Der findes en artikel i FOB 2023 med titlen »Gode it-systemer kræver god forberedelse«.

Tekniske og integrationsmæssige krav

Åbne standarder er et selvstændigt kravområde, uanset om softwaren er open source eller proprietær. Vejledningen kalder åbne standarder det fælles sprog, systemerne bruger til at tale sammen og forstå hinanden, og fremhæver, at de fremmer konkurrence på softwaremarkedet og gør det muligt for offentlige it-systemer at udveksle informationer på tværs uanset softwarevalg.

Kravet bør derfor skrives som en liste af konkrete grænseflader og dataformater – ikke som en generel hensigtserklæring om åbenhed.

Afhængigheder udgør den anden halvdel af de tekniske krav. I praksis betyder det, at man bør kortlægge, hvilke komponenter der ikke kan udskiftes uden at bryde integrationer, og hvor i arkitekturen afhængigheden sidder.

I en fællesoffentlig kontekst skal integrationerne navngives eksplicit. MitID, Digital Post, borger.dk, NemKonto, Digital Fuldmagt og MitID Erhverv er blandt de løsninger, Digitaliseringsstyrelsen beskriver som fællesoffentlige it-løsninger udviklet i samarbejde med øvrige danske offentlige myndigheder og virksomheder.

Styrelsen henviser til servicedeklarationen for driftsstatus og kontaktinformation til support på de fællesoffentlige it-løsninger. Med afsæt i den kan krav om, hvem der supporterer hvad, og hvornår en tjeneste forventes tilgængelig, formuleres.

Licens-, ansvars- og vedligeholdelseskrav

Licensvilkårene afgør, hvem der kontrollerer løsningen. Ved proprietær software beholder softwareleverandøren fuld kontrol over kildekoden og distributionen, mens myndigheden køber en licens til at bruge softwaren under specifikke, ofte begrænsede betingelser.

En open source-licens giver derimod enhver ret til frit og til ethvert formål at bruge, undersøge, ændre og dele softwaren og dens kildekode.

Ansvarsskiftet er den praktiske konsekvens. Digitaliseringsstyrelsen formulerer det sådan, at myndigheden skal tage større ansvar for den anvendte it-løsning, hvis den vælger open source-software frem for at købe proprietær software hos en leverandør.

Mere konkret skal myndigheden i højere grad have styr på licensvilkår, sikkerhedsopdateringer, fejl, support og vedligeholdelse af softwaren. Det bør nedfældes som krav i aftalen: hvem retter fejl, hvem vurderer og godkender opdateringer, og hvem dokumenterer det.

Der findes en vigtig mellemform, som kravtyperne skal kunne rumme. Rapporten nævner, at open source-løsningen i nogle tilfælde stilles til rådighed af en organisation eller en privat leverandør, og at kravene til myndigheden her ikke nødvendigvis er højere end ved proprietær software.

Kravtyperne bør derfor knyttes til den konkrete driftsmodel – hvem der stiller løsningen til rådighed, og hvem der vedligeholder den – ikke til softwarekategorien alene.

Sikkerhed-, databeskyttelses- og risikokrav

Sikkerhedsopdateringer bør beskrives som en proces – hvordan sårbarheder opdages, vurderes, udbedres og dokumenteres – og ikke kun som en egenskab ved produktet. Det gælder uanset licensmodel.

Ikke al software bør deles i sin helhed. Rapporten peger på, at når open source-software deles, er det vigtigt at være opmærksom på, at nogle systemer er underlagt særlige rammer.

Det gælder for eksempel kritisk infrastruktur, hvor det ikke er hensigtsmæssigt at offentliggøre softwaren som open source i sin helhed. Et krav om åbenhed skal derfor afgrænses konkret: hvilke dele af koden kan offentliggøres, og hvilke dele er omfattet af særlige rammer.

Databeskyttelse skal indgå som konsekvensvurdering, ikke som eftertanke. Ved softwarevalg bør rækkefølgen være den samme som i arbejdet med digitaliseringsklar lovgivning: Afklar først, hvilke oplysninger løsningen behandler, hvilke risici det indebærer, og hvilke sikkerhedskrav det udløser – og lad det styre valget af løsning, ikke omvendt.

Sammenligning af kravtyper i softwarevalg: Open source vs. proprietær software

Organisatoriske og kompetencemæssige krav

Rapporten konkluderer, at der er perspektiver i brug af open source, men at det forudsætter, at myndigheder kan opbygge de nødvendige ressourcer. Erfaringerne viser også, at mindre it-organisationer har sværere ved det.

Kompetencekravet er derfor ikke et blødt krav, men kan vurderes konkret: hvilke opgaver skal kunne løses internt i organisationen, og hvilke kan købes?

For de mindre organisationer findes en dokumenteret udvej: I nogle tilfælde kan de købe relevante open source-kompetencer fra eksterne leverandører. Det bør indgå som en selvstændig kravtype – hvilke kompetencer skal være tilgængelige på hvilke tidspunkter, og hvordan sikres adgangen til dem over kontraktperioden?

Økonomiske og driftsmæssige krav over livscyklussen

Økonomiske krav skal dække hele livscyklussen, ikke kun anskaffelsen. Licensmodellen er en del af billedet, men rapporten peger også på, at det koster at tage ny software i brug – både i tekniske og organisatoriske tilpasninger.

De kompetencer, der er nødvendige for implementering og drift, skal derfor også indgå i vurderingen.

Ved open source flytter der også arbejdsopgaver ind i regnestykket. De opgaver, som open source-modellen lægger hos myndigheden, skal prissættes over hele livscyklussen – anskaffelse og implementering, integration, drift, vedligeholdelse og kompetenceopbygning – uanset om de løses internt eller købes hos en leverandør.

For at kunne sammenligne to tilbud bør hver post derfor opgøres ens for begge løsninger.

Afhængigheds- og genbrugskrav: Inbound og outbound

Rapporten skelner mellem inbound og outbound: Det er ikke det samme, om myndigheder og andre organisationer anvender open source-software (inbound), eller om de også bidrager med open source-software, som andre kan bruge (outbound).

Valget påvirker, hvilke krav der skal stilles til egne udviklings- og leverandøraftaler. Det er nemlig ikke samme opgave at modtage kode som at levere den videre i en form, andre kan bruge.

Genbrug er den gevinst, som flere myndigheder peger på. De interviewede myndigheder ser et potentiale for øget brug af open source-software på udvalgte områder, og det er for eksempel en fordel at genbruge kode mellem myndigheder.

Samtidig mangler de ofte ressourcerne til at dele den kode, de selv har udviklet – en praktisk udfordring på outbound-siden. Der findes konkrete danske eksempler på deling: 82 kommuner bruger OS2kitos, ofte sammen med et af de andre 21 OS2-produkter.

Afhængighedskravet handler om at kunne skifte løsning. Vejledningen beskriver, at offentlige myndigheder så vidt muligt undgår løsninger, der skaber afhængighed af specifikke leverandører og teknologier, og at de hvor det er relevant kan anvende bæredygtige open source-komponenter.

Rapporten peger samtidig på en række vanskelige afhængigheder til proprietær software. Kravet bør derfor formuleres som en konkret exit-mulighed: Hvad kræver det at udskifte komponenten, hvem kan gøre det, og hvilke data og integrationer skal flyttes med?

Statistisk oversigt over open source-brug i danske myndigheder

Prioritering: Skal- og bør-krav i beslutningen

Prioriteringen må tage højde for, at kravtyperne vægter forskelligt fra opgave til opgave. Et sagsbehandlingssystem og et tekstbehandlingsværktøj udløser ikke de samme skal-krav.

Skal-kravene er dem, myndigheden ikke selv kan disponere over. Det gælder de forvaltningsretlige krav, som er beskrevet i afsnittet om sagsbehandling og dokumentation, og de krav, som digitaliseringsklar lovgivning udløser.

Bør-kravene er de strategiske valg, hvor der findes et alternativ. Åbne standarder, undgåelse af afhængighed af specifikke leverandører og teknologier, genbrug af kode mellem myndigheder og bæredygtige open source-komponenter følger af vejledningen og de strategiske valg. De skal derfor afvejes i det enkelte softwarevalg.

Bredt anvendte værktøjer kan derimod vurderes med større ro: LibreOffice til tekstbehandling og QGIS til geodatabehandling er eksempler på open source-software, som danske offentlige myndigheder allerede bruger.

Prioriterede kravtyper efter betydning i softwarevalg