Langt perspektiv

Perspektiver for skytjenester og portabilitet når man har middels lang tid for endring

Scenarioet beskriver en situasjon der behovet for konkrete endringer aktualiserer seg innenfor et tidsrom på 6 måneder - 3 år. Behovet kan være foranlediget av situasjoner som for eksempel endrede regulatoriske rammer enten nasjonalt eller på EU-nivå, og endrede prioriteringer eller føringer fra ledelse eller politisk hold. Felles for situasjonene er at behovet for endring ikke oppstår akutt, men blir synlig på litt lengre sikt, og at det derfor er noe tid til å vurdere alternativer og kartlegge konsekvenser på en grundig måte.

Strategisk tilnærming

I det mellomlangsiktige perspektivet bør virksomhetens strategiske fokus være en aktiv styrking av egen endringskapasitet. Det innebærer at virksomheten ikke bare skal ha planer for en eventuell utfasing av eksisterende skytjenester, men gradvis bygge de tekniske, organisatoriske og kontraktsmessige forutsetningene som gjør en slik utfasing praktisk gjennomførbar.

Formålet er å etablere broene mellom dagens driftsmodell og mulige fremtidige alternativer. Dette skal skje uten at daglig drift svekkes eller at virksomheten påtar seg unødvendig kompleksitet. Den mellomlangsiktige strategien bør derfor handle om å redusere avhengigheter, teste realistiske alternativer og utvikle kompetanse som gjør virksomheten i stand til å gjennomføre endringer kontrollert dersom behovet oppstår.

I denne fasen bør virksomheten legge vekt på tiltak som øker fleksibiliteten over tid. Det betyr at arkitektur, dataforvaltning, leverandørstyring og organisasjonsutvikling må ses i sammenheng. Endringskapasitet skapes ikke gjennom enkeltstående tiltak, men gjennom en samlet utvikling av løsninger, prosesser og kompetanse som gjør virksomheten mindre sårbar for teknologiske eller kommersielle bindinger.

Følgende prinsipper bør styre arbeidet i denne fasen:

Etablering av vendbare arkitekturmønstre

Virksomheten bør gradvis bevege seg bort fra dype, proprietære integrasjoner og over til en mer modulær og vendbar arkitektur. Med dette menes en arkitektur der sentrale tjenester, dataflyter og integrasjoner kan flyttes, erstattes eller kobles om, uten at hele systemlandskapet må bygges på nytt.

En slik tilnærming reduserer risikoen for at virksomheten blir teknisk bundet til én bestemt leverandør, og gir bedre forutsetninger for å gjennomføre fremtidige endringer kontrollert. Arkitekturen bør derfor utformes slik at avhengigheter blir synlige, dokumenterte og håndterbare.

Abstraksjon: Mellomvare, API-lag og integrasjonsplattformer bør brukes strategisk for å frikoble applikasjoner fra den underliggende skyinfrastrukturen. Dette gjør det enklere å endre eller erstatte tekniske komponenter, uten at hele applikasjonsporteføljen påvirkes. Abstraksjon bør ikke innføres som et mål i seg selv, men der det gir reell reduksjon av leverandøravhengighet og styrker virksomhetens evne til å flytte tjenester mellom miljøer.

Data-frikobling: Virksomheten bør sikre at data lagres, struktureres og dokumenteres på en måte som understøtter portabilitet. Det innebærer blant annet å unngå unødvendig avhengighet til leverandørspesifikke databasemotorer, proprietære lagringsformater eller lukkede analyseverktøy. Data bør kunne eksporteres, valideres og gjenbrukes i alternative miljøer uten omfattende ombygging. Dette er avgjørende for at virksomheten skal beholde reell råderett over egne data.

Aktiv redundans og «reverse cloud»-testing

En teoretisk exit-plan har liten verdi hvis virksomheten ikke har praktisk erfaring med alternativ drift. I det mellomlangsiktige perspektivet bør virksomheten derfor bygge gradvis erfaring med løsninger som kan fungere utenfor dagens primære skyleverandør. Dette kan gjøres gjennom avgrensede piloter, beredskapsøvelser, speiling av data, hybrid drift eller testflytting av mindre kritiske tjenester.

Hensikten er ikke nødvendigvis å etablere full parallell drift, men å skape realistisk kunnskap om hva som faktisk kreves for å flytte, gjenopprette eller drifte tjenester i et annet miljø. Slik erfaring gir bedre beslutningsgrunnlag, avdekker skjulte avhengigheter og gjør virksomheten bedre forberedt på en kontrollert overgang.

Hybrid drift i praksis: Virksomheten bør vurdere om enkelte støttefunksjoner, testmiljøer eller speilede datasett kan kjøres lokalt, i privat sky eller hos alternative leverandører. Dette kan bidra til å opprettholde teknisk kompetanse på flere plattformer og redusere risikoen for at virksomheten kun mestrer én driftsmodell. Hybrid drift bør brukes målrettet der det gir læring, robusthet eller strategisk fleksibilitet, og ikke innføres som generell kompleksitet uten tydelig formål.

Migrasjonsøvelser: Virksomheten bør gjennomføre tekniske piloter der mindre kritiske tjenester faktisk flyttes mellom miljøer. Slike øvelser gir praktisk innsikt i hvor lang tid flytting tar, hvilke data- og integrasjonsavhengigheter som oppstår, hvilke kompetansebehov som melder seg, og hvilke kostnader som er knyttet til migrasjon. Erfaringene bør dokumenteres og brukes til å forbedre arkitektur, kontrakter, beredskapsplaner og fremtidige anskaffelser.

Leverandørstyring og utgangsforberedelser

I denne fasen bør virksomheten profesjonalisere leverandørstyringen med særlig vekt på leverandørenes evne og plikt til å støtte en eventuell utfasing. Exit beredskap bør behandles som en del av ordinær kontrakts- og leverandøroppfølging, ikke som et tema som først aktualiseres når virksomheten har besluttet å flytte.

Dette innebærer at virksomheten må ha oversikt over kontraktsmessige rettigheter, tekniske avhengigheter, uttakskostnader, dokumentasjonskrav og leverandørens ansvar ved overgang til ny løsning. Slik kunnskap gir bedre kontroll og reduserer risikoen for uforutsette hindringer, dersom en utfasing blir aktuell.

Kontraktsmessig modning: Virksomheten bør starte arbeidet med å revidere eksisterende avtaler for å sikre tydeligere krav til bistand ved utfasing, datauttrekk, dokumentasjon, overgangsstøtte og håndtering av egress-kostnader. Kontraktene bør også tydeliggjøre hvilke formater, tidsfrister, sikkerhetskrav og støtteforpliktelser som gjelder, dersom data eller tjenester skal flyttes. Dette gir større forutsigbarhet og reduserer risikoen for at virksomheten møter kommersielle eller juridiske barrierer sent i prosessen.

Alternativkartlegging: Virksomheten må holde oversikt over konkrete alternative mottakere av tjenester og data. Dette kan omfatte norske datasentre, private skyløsninger, sektorvise fellesløsninger eller andre offentlige skyleverandører. Formålet er ikke å velge en ny leverandør på forhånd, men å forstå markedets kapasitet, modenhet, sikkerhetsnivå og evne til å overta relevante volumer. Slik kartlegging gjør fremtidige beslutninger mer realistiske og mindre preget av tidspress.

Organisasjonsutvikling og brobyggerkompetanse

Endringskapasitet forutsetter at organisasjonen har kompetanse som kan bygge bro mellom dagens skymodell og mulige alternative driftsformer. Dersom virksomheten kun utvikler kompetanse knyttet til én leverandørs plattform, blir risikoen stor for at både tekniske beslutninger og fremtidige handlingsalternativer blir styrt av leverandørens premisser.

Virksomheten bør derfor utvikle en bredere kompetanseprofil, som omfatter offentlig sky, privat sky, lokal infrastruktur, sikkerhetsarkitektur, dataforvaltning, automatisering og leverandørstyring. Dette gjør organisasjonen bedre i stand til å vurdere alternativer, planlegge overgangsløp og gjennomføre tekniske endringer uten å miste styring.

Krysstrening: Personell som i dag hovedsakelig arbeider med offentlig sky, bør trenes i arkitekturprinsipper for lokal infrastruktur, privat sky og hybrid drift. Tilsvarende bør personell med erfaring fra tradisjonell infrastruktur få innsikt i moderne skyarkitektur, automatisering og skaleringsprinsipper. Målet er å utvikle en organisasjon som forstår flere driftsmodeller og kan vurdere dem opp mot virksomhetens behov, risiko og strategiske mål.

Prosess-standardisering: Virksomheten bør utvikle standardiserte rutiner for provisjonering, utrulling, overvåking og endringshåndtering som kan fungere på tvers av ulike driftsmiljøer. Bruk av prinsipper som «Infrastructure as Code», automatiserte utrullingsløp og standardiserte konfigurasjoner kan bidra til at tjenester lettere kan flyttes eller gjenopprettes i alternative miljøer. Standardisering bør derfor sees på som et strategisk virkemiddel for fleksibilitet, ikke bare som et effektiviseringstiltak.

Tekniske valg

Scenarioet ‘middels lang tid for endring’ gir noe rom for tilrettelegging av tekniske løsninger og standarder for å understøtte skytjenesteportabilitet.

For å sikre portabilitet bør virksomheten aktivt tilrettelegge for å:

• Unngå unødvendig bruk av proprietære skylåste tjenester der det finnes portable alternativer som er basert på åpen kildekode
• Standardisere på åpne formater og dokumenterte grensesnitt
• Bruke infrastruktur- og konfigurasjonsbeskrivelser som kan gjenbrukes på tvers av plattformer
• Sikre at identitets- og tilgangsforvaltning ikke er ensidig bundet til én skyplattform
• Etablere løsninger for logging, nøkkelhåndtering, backup og overvåking som kan flyttes eller gjenskapes

Teknisk tilrettelegging for skytjenesteportabilitet

Infrastructure-as-a-Service (IaaS)

Overordnet anbefaling for IaaS-området er å redusere konsentrasjonsrisiko ved å legge til rette for hybrid- eller multisky, hvor driften av løsningene vil være taktisk separert i Norge/Skandinavia/Europa.

Følgende tilnærminger kan understøtte dette:

• Hybridtilkobling: Etablere sikre forbindelser (f.eks. VPN/IPsec) mellom nåværende sky og alternative lokasjoner i Norge/Europa.
• Uavhengige støttetjenester: Etablere løsninger for backup, logging og overvåking som er flyttbare eller kan gjenskapes uavhengig av plattformen.
• Standardisert objektlagring: Benytte lagringsløsninger som støtter åpne API-standarder for å forenkle synkronisering av data mellom ulike leverandører.
• Uavhengig loggaggregasjon: Sørge for at logger sendes til en nøytral lokasjon (i Norge/Europa) i sanntid, slik at historiske data er tilgjengelige selv om primærskyen blir utilgjengelig.
• Båndbreddeanalyse: Kartlegge faktiske overføringstider og eventuelle kostnader (“egress fees”) for kritiske datasett, for å sikre at en flytting er praktisk gjennomførbar innenfor tidskravet.
• Kontinuerlig datasynkronisering: Etablere løpende asynkron replikering av store datasett til en uavhengig lokasjon i Norge/Europa, for å nøytralisere "data-tyngdekraft" ved behov for flytting. Innføre hyppig integritetsvalidering av de replikerte dataene, for å verifisere at måldataene faktisk er lesbare uten opprinnelig applikasjonslogikk.
• Latencytesting: Gjennomføre målinger av forsinkelse mellom nåværende sky og potensielle mottaksmiljøer, for å vite hvilke applikasjoner som tåler splittet drift.

Platform as a Service (PaaS)

Overordnet anbefaling for PaaS-området er å redusere konsentrasjonsrisiko, ved å implementere eller legge til rette for hybrid- eller mulitisky der minst ett ben er i Norge/Skandinavia/Europa.

Følgende tilnærminger kan understøtte dette:

• Abstraksjonslag for databaser: Identifisere og planlegge utfasing av proprietære funksjoner til fordel for portable alternativer som støtter standardisert SQL (ISO/IEC 9075). Dette for å redusere terskelen for migrering mellom ulike databaseplattformer
• Logghåndtering: Sentralisere logging via åpne protokoller som Syslog eller standardiserte telemetriformater, for å bevare sporbarhet på tvers av plattformer.
• Gjenbrukbar konfigurasjon: Bruke konfigurasjonsbeskrivelser som kan tolkes og gjenbrukes på tvers av ulike skyplattformer.
• Standardisert telemetri: Implementere overvåking basert på OpenTelemetry. Dette sikrer at logger, metrikker og sporingsdata (traces) kan sendes til et nytt miljø uten at applikasjonskoden må skrives om.
• “Dry-run” av Infrastructure as Code (IaC): Kjøre regelmessige tester der IaC-skript rulles ut i et tomt testmiljø hos en annen leverandør, for å avdekke skjulte tekniske avhengigheter. KI kan gi effektivt bistand til å tilpasse IaC til ulike leverandører.
• Validering av API-bakoverkompatibilitet: Ved versjonsoppdateringer av plattformen, kreve teknisk dokumentasjon som eksplisitt spesifiserer endringer i API-grensesnitt, for å sikre at automatiserte integrasjoner forblir funksjonelle i en migreringsfase.

Software-as-a-Service (SaaS)

Overordnet anbefaling for SaaS-området er å redusere konsentrasjonsrisiko ved å legge til rette for reserveløsning i Norge/Skandinavia/Europa. Anbefalingene tar ikke stilling til kontorstøtte-relatert SaaS.

Følgende tilnærminger kan understøtte dette:

• Teknisk reserveløsning: Legge til rette for reserveløsninger for kritiske tjenester i Norge eller Europa, for å redusere risiko.
• Eksportrutiner: Etablere automatiserte rutiner for periodisk eksport av virksomhetsdata, til en uavhengig lagringslokasjon i Norge eller Europa.
• Eksport- og integrasjonstesting: Gjennomføre faktiske tester av dataportabilitet, og bruke SCIM (System for Cross-domain Identity Management) for synkronisering av identiteter for å sikre at virksomheten faktisk kan flytte.
• Inkrementell dataeksport: Etablere tekniske rutiner for løpende eksport av endringer i datasett (Change Data Capture - CDC), fremfor å basere seg på tunge full-eksporter som kan feile ved båndbreddebegrensninger.
• SLA for eksportgrensesnitt: Spesifisere tekniske krav til oppetid og ytelse (SLA) som gjelder spesifikt for leverandørens grensesnitt for datauttrekk, slik at virksomheten er garantert stabil tilgang til egne data også ved avvikling.

Perspektiver for skytjenester og portabilitet når man har lang tid for endring

Med typisk 3–10 år mellom leverandøranskaffelser er tidsbildet for offentlige skytjenester langsiktig. Virksomheten må ha en strategi for fremtidig leverandørskifte, selv om den operative situasjonen er stabil. På teknisk side kan teknologilandskapet endre seg betydelig i tidsrommet, noe som gjør at det ikke er hensiktsmessig å foreta detaljerte tekniske valg for portering av tjenester og data. Likevel må plattformtjenester og infrastruktursystemer forbli fleksible nok til å muliggjøre konkurranse mellom flere leverandører når en anskaffelse skal gjennomføres i fremtiden.

I dette scenarioet inntreffer ingen uforutsette hendelser: daglig drift er stabil, leverandøren oppfyller avtalte SSA-er (SLA), og regulatoriske rammer endres ikke på en måte som påvirker løsningen. Den strategiske styringen må fokusere på å bevare valgfrihet og reell konkurranse ved neste planlagte anskaffelse. Kontraktene og tilhørende tiltak er utelukkende rettet mot denne kommende konkurransen: sikring av endringsevne, dokumentert dataportabilitet og rett til overgangsbistand, samtidig som markedet overvåkes og kravsettet modnes — uten å aktivere opsjoner eller beredskapsmekanismer før selve anskaffelsen.

Strategisk tilnærming

Over tid bør målet med virksomhetens skystrategi være å redusere risikoen for uønsket leverandørbinding, og å sikre reell råderett over egne data, tjenester og teknologiske veivalg i markedet. Siden offentlige skytjenester normalt anskaffes og forvaltes over lange tidshorisonter, må virksomheten ha en strategisk tilnærming som ikke bare ivaretar dagens operative behov, men også bevarer fremtidig handlingsrom.

En langsiktig strategisk tilnærming innebærer at virksomheten bygger en arkitektur, en kontraktsportefølje og en organisasjon som ikke blir unødig avhengig av én leverandør eller ett bestemt teknologisk økosystem. Formålet er ikke nødvendigvis å legge til rette for hyppige leverandørskifter, men å sikre at et fremtidig skifte er praktisk, teknisk, økonomisk og juridisk mulig dersom virksomhetens behov, markedet eller rammebetingelsene endrer seg. Dette forutsetter at flyttbarhet og portabilitet behandles som strategiske styringshensyn, ikke som rene tekniske detaljer. Virksomheten bør derfor bruke sitt handlingsrom aktivt i dialog med markedet, både gjennom kravstilling, kontraktsforhandlinger, arkitekturvalg og løpende modernisering.

Følgende strategiske prinsipper bør ligge til grunn for det langsiktige arbeidet:

Kommersielt handlingsrom og kontraktsforhandlinger

Virksomheten bør utvikle og vedlikeholde en reell evne til utfasing som strategisk virkemiddel i møte med skyleverandører. Dette innebærer at virksomheten må kunne dokumentere hvordan data, tjenester og sentrale avhengigheter kan overføres eller avvikles ved behov. En slik evne gir ikke bare operativ trygghet, men styrker også virksomhetens posisjon i kommersielle prosesser.

Forhandlingsmakt: Ved å ha troverdige exit-planer, oversikt over avhengigheter og en teknisk arkitektur som tillater flytting, stiller virksomheten vesentlig sterkere i kontraktsforhandlinger. Dette gjelder både ved reforhandling av eksisterende avtaler og ved nye anskaffelser. Når leverandøren vet at virksomheten har et reelt alternativ, økes virksomhetens mulighet til å påvirke pris, tjenestenivå, sikkerhetskrav, personvernkrav og vilkår for videreutvikling.

Strategisk innkjøp: Virksomheten bør bruke kontraktsrevisjoner og nye anskaffelser til å sikre bedre vilkår for datauttrekk, portabilitet, dokumentasjon og støtte ved eventuell migrasjon. Dette bør inngå som en fast del av anskaffelsesstrategien, ikke som et tilleggskrav sent i prosessen. Avtalevilkår som i praksis binder virksomheten til én løsning gjennom proprietære formater, høye uttakskostnader, manglende overgangsstøtte eller begrenset tilgang til dokumentasjon, må ikke aksepteres.

Kontinuerlig modernisering og teknisk gjeld

Langsiktig strategisk handlefrihet krever at virksomheten arbeider aktivt med å identifisere og redusere teknisk gjeld som kan begrense fremtidig fleksibilitet. Over tid kan systemer, integrasjoner og plattformvalg utvikle seg til bindinger som gjør det svært krevende å endre leverandør, modernisere tjenester eller gjennomføre nye anskaffelser med reell konkurranse.

Utskifting av arv: Eldre systemer som er tett sammenvevd med spesifikk infrastruktur, leverandørspesifikke tjenester eller proprietære integrasjoner, bør vurderes særskilt i virksomhetens langsiktige moderniseringsplaner. Der slike systemer utgjør en barriere for fremtidig fleksibilitet, bør de moderniseres, isoleres eller fases ut til fordel for mer standardiserte og flyttbare løsninger. Dette bør skje som del av ordinær porteføljestyring, ikke først når en migrasjon blir nødvendig.

Innebygd flyttbarhet: Nye systemer bør vurderes ut fra hvor godt de understøtter portabilitet, åpne grensesnitt, dokumentert dataflyt og mulighet for fremtidig leverandørskifte. Skybasert utvikling bør ikke forstås som en ensidig tilpasning til én leverandørs økosystem. Å være «Cloud native» må innebære at løsningene er moderne, skalerbare og automatiserbare uten å skape unødvendig avhengighet til proprietære tjenester eller formater.

Kompetanse som strategisk aktivum

For å unngå å bli prisgitt leverandørenes premisser, bør virksomheten eie den overordnede systemforståelsen selv. Leverandører kan levere teknologi, drift og spesialistkompetanse, men virksomheten må selv ha tilstrekkelig innsikt til å forstå egne avhengigheter, stille presise krav og vurdere konsekvensene av tekniske og kommersielle valg.

Bestillerkompetanse: Virksomheten bør ha tilstrekkelig intern kompetanse til å forstå hvordan egne tjenester er bygget opp, hvilke data som behandles, hvilke integrasjoner som er kritiske, og hvilke avhengigheter som finnes mot leverandørens plattform. Dette er nødvendig for å kunne styre anskaffelser, kontraktsoppfølging, migrasjonsvurderinger og sikkerhetsmessige avklaringer, uten å være fullt ut avhengig av leverandørens egne konsulenter eller andre korttidsansatte.

Arkitekturkontroll: Kontrollen over den logiske arkitekturen bør ligge hos virksomheten, selv om selve driften eller deler av utviklingen settes ut. Virksomheten bør selv eie målarkitekturen, prinsippene for integrasjon, kravene til dataflyt og vurderingene av hvilke avhengigheter som er akseptable. Dette gir bedre grunnlag for å styre leverandører, redusere risiko for innlåsing, og sikre at teknologiske valg understøtter virksomhetens langsiktige behov.

Tekniske valg

Scenarioet med lang tid for endring gir godt rom for teknisk tilrettelegging og kontraktstilpasninger, for å understøtte skytjenesteportabilitet.

For å sikre portabilitet bør virksomheten aktivt tilrettelegge for å:

• Unngå unødvendig bruk av proprietære skylåste tjenester, der det finnes portable alternativer som er basert på åpen kildekode
• Standardisere på åpne formater og dokumenterte grensesnitt
• Bruke infrastruktur- og konfigurasjonsbeskrivelser som kan gjenbrukes på tvers av plattformer
• Sikre at identitets- og tilgangsforvaltning ikke er ensidig bundet til én skyplattform
• Etablere løsninger for logging, nøkkelhåndtering, backup og overvåking som kan flyttes eller gjenskapes

Teknisk tilrettelegging for skytjenesteportabilitet

Infrastructure-as-a-Service (IaaS)

Overordnet anbefaling for IaaS-området er å redusere konsentrasjonsrisiko ved å legge til rette for hybrid- eller multisky, hvor driften av løsningene vil være taktisk separert i Norge/Skandinavia/Europa.

Følgende tilnærminger kan understøtte dette:

• Deklarativ infrastruktur: All infrastruktur må defineres som kode (IaC) i plattformnøytrale formater, slik at miljøet kan gjenskapes uavhengig av leverandørens egne verktøy. Med plattformnøytrale formater menes åpne spesifikasjoner (f.eks. deklarative YAML/JSON-strukturer som tolkes av uavhengige motorer). Dette sikrer at man unngår avhengighet av leverandørspesifikke utrullingsskript.
  Ved å anvende KI kan deklarative infrastrukturdefinisjoner analyseres, normaliseres og konverteres til ekvivalente implementasjoner på tvers av ulike skyplattformer, noe som forenkler migrasjon og styrker interoperabilitet.
• Standardisert virtualisering: Basere arkitekturen på åpne hypervisor-standarder og formater, som muliggjør flytting av virtuelle maskiner mellom ulike datasentre.
• Hybrid- og multiskyberedskap: Implementere eller legge til rette for løsninger der minst ett teknisk "ben" er plassert i Norge eller Europa for å redusere konsentrasjonsrisiko.
• Nøytral nettverksarkitektur: Benytte standardiserte rutingprotokoller og IPv6 for å unngå avhengighet av leverandørspesifikke nettverksfunksjoner.
• Plattformnøytral hemmelighets- og nøkkelstyring (Secrets & Key Management): Bruke en leverandøruavhengig hvelvtjeneste. Denne må omfatte kryptografiske nøkler (f.eks. BYOK), applikasjonshemmeligheter (passord, API-tokens, secrets) og sertifikater, slik at tillitskjeder og tilgangsmekanismer kan porteres uavhengig av skyplattform.
• Automatisert sertifikatbehandling: Bruke ACME-protokollen for automatisert utstedelse og fornyelse av sikkerhetssertifikater, slik at man unngår avhengighet av leverandørspesifikke sertifikatautoriteter.
• Nettverksidentitet - Bring Your Own IP (BYOIP): Stille tekniske krav om støtte for å annonsere egne IP-adresseområder via BGP (Border Gateway Protocol), slik at man kan flytte infrastruktur uten å rekonfigurere eksterne endepunkter.
• Leverandøruavhengig SDN-kontroll: Bruke programvaredefinerte nettverk (SDN) som styres via åpne protokoller, slik at nettverkssegmentering og sikkerhetsregler kan speiles direkte til en ny leverandør.
• Krav til selvbetjente “exit-verktøy”: Stille tekniske krav om at leverandøren skal tilby dokumenterte, selvbetjente mekanismer (f.eks. API-er eller CLI-verktøy) for fullstendig eksport av virtuelle maskiner og lagringsvolumer, uten behov for manuell bistand fra leverandøren.
• Maskinlesbar ressurstaksonomi (tagging): Implementere et teknisk krav om at alle ressurser skal støtte metadatatagging som identifiserer systemtilhørighet, slik at automatiserte migreringsverktøy kan identifisere og flytte komplette tjenestekjeder som en enhet.

Platform as a Service (PaaS)

Overordnet anbefaling for PaaS-området er å redusere konsentrasjonsrisiko ved å legge til rette for hybrid- eller multisky, hvor driften av løsningene vil være taktisk separert i Norge/Skandinavia/Europa.

Følgende tilnærminger kan understøtte dette:

• Container-standardisering: Applikasjoner bør pakkes i enheter basert på OCI (Open Container Initiative)-standarder for å frikoble programvaren fra den underliggende skyplattformen.
• Standardisert meldingsutveksling: Bruke åpne protokoller som AMQP eller MQTT for kommunikasjon mellom komponenter, for å unngå proprietær låsing.
• Plattformuavhengig identitet: Implementere autentisering via OIDC (OpenID Connect) og SAML 2.0, for å frikoble brukertilganger fra leverandørens katalogtjeneste og sikre at identitetsforvaltning ikke er ensidig bundet til én leverandør.
• Plattformuavhengig API-gateway: Unngå dyp integrasjon med leverandørspesifikke API-gateways. Benytte løsninger som kan kjøres i containere og støtter OpenAPI-spesifikasjoner, for å sikre at trafikkstyring, autentisering og "rate limiting" er flyttbare. Selve konfigurasjonen (rutingregler, sikkerhetspolicyer) må lagres i et standardisert format (f.eks. som deklarative policyer), slik at hele integrasjonsmønsteret kan flyttes uten manuell rekonfigurering.
• Service Mesh for intern kommunikasjon: Vurdere bruk av et "Service Mesh" basert på åpne standarder for å håndtere tjenesteoppdagelse (“service discovery”) og kryptering mellom komponenter, slik at tjenester kan finne hverandre uavhengig av hvilket nettverk de befinner seg i.
• Standardisert ressurstagging: Innføre en streng teknisk taksonomi for tagging av ressurser, slik at automatiserte verktøy kan identifisere hvilke komponenter som hører sammen og må flyttes som en enhet.
• Standardisert Telemetri og Tracing: All applikasjonsovervåking, logging og sporing bør instrumenteres ved bruk av åpne telemetristandarder (OpenTelemetry). Dette sikrer at applikasjonskoden er portabel, slik at man kan flytte tjenesten til et nytt mottaksmiljø uten å måtte skrive om koden for å tilpasse den til en ny leverandørs overvåkingsverktøy.
• Tjenester basert på åpen kildekode: Ved å velge PaaS-tjenester som er basert på åpen kildekode som tilbys på tvers av flere leverandører, forenkles både migrering og multisky. Vanlige eksempler på dette er PostgreSQL for database og Kubernetes og CNCF-økosystemet for container-plattform.
• Åpne modeller og standardiserte grensesnitt for KI: Der det er mulig bør man benytte store språkmodeller (LLM) som er åpne og kan tilgjengeliggjøres på tvers av ulike leverandører. Standardiserte eller de-facto grensesnitt for språkmodeller via API bør benyttes. I en ideell situasjon tilgjengeliggjøres APIer for språkmodeller bak en felles KI-gateway, slik at man kan endre leverandører uten å endre alle konsumenter. De samme grunnleggende prinsippene relatert til åpen kildekode og standardiserte grensesnitt gjelder med andre ord også for KI.

Software-as-a-Service (SaaS)

Overordnet anbefaling for SaaS-området er å redusere konsentrasjonsrisiko ved å legge til rette for reserveløsning i Norge/Skandinavia/Europa. Anbefalingene tar ikke stilling til kontorstøtterelatert SaaS.

Følgende tilnærminger kan understøtte dette:

• Strukturerte dataformater og eierskap: Sikre teknisk rett og evne til å hente ut data i åpne, maskinlesbare formater som JSON, XML eller CSV. Kreve at data lagres og kan eksporteres i åpne formater.
• Standardiserte grensesnitt: Prioritere tjenester med integrasjoner via RESTful API med OpenAPI-dokumentasjon, for å forenkle fremtidige bytter.
• Teknisk dokumentasjon i åpne formater: Spesifisere at all systemarkitektur, databaseskjemaer og API-dokumentasjon skal leveres og oppdateres i åpne, redigerbare formater (som Markdown eller HTML), slik at teknisk innsikt er portabel ved leverandørbytte.
• Standardisert brukerprovisjonering: Ved anskaffelse av SaaS-tjenester bør det kreves støtte for identitetsstyring basert på åpne standarder for brukersynkronisering (eks. SCIM). Dette sikrer at virksomheten automatisk kan trekke tilbake eller flytte tilganger for samtlige brukere simultant, i stedet for å måtte håndtere identiteter manuelt i leverandørens lukkede portal.