# Hva må på plass for at en kobling mellom to systemer skal være til å stole på over tid? En integrasjon som virker i en test, er ikke det samme som en integrasjon dere kan stole på i hverdagen. Her er sju krav som skiller de pålitelige fra de skjøre, med eksempler, avveininger og en sjekkliste å bruke før dere bestiller eller bygger. - **Type:** Artikkel - **Tema:** Integrasjoner - **Publisert:** 26\. oktober 2026 - **Les hvis:** Dere skal koble sammen systemer, for eksempel nettbutikk og regnskap, og vil unngå dobbeltregistrering, tapte data og overraskelser. - **Hovedpoenget:** Det vanskelige med integrasjoner er sjelden å flytte data når alt går bra. Det er å håndtere feil, endringer og tilgang på en trygg måte. - **Artikkelen tar opp:** Hvem eier opplysningene, Feil og gjentak, Tilgang og sikkerhet, og Sjekkliste. - **Nettside:** En systemintegrasjon er en kobling som lar to eller flere systemer utveksle opplysninger automatisk, for eksempel at ordre fra nettbutikken havner i regnskapet uten at noen taster dem inn på nytt. Når den virker, merker ingen den. Når den svikter, merker alle det, ofte først når tallene ikke stemmer. Det er sjelden selve dataflyttingen som er vanskelig. Det er alt som kan gå galt rundt den. Her er sju ting som bør være avklart. Eksemplene er tenkte og laget for å illustrere. ## Sju krav ### Ett system eier hver opplysning Bestem hvilket system som har den riktige versjonen av hver opplysning: kundeadressen i kundesystemet, prisene i økonomisystemet, lagerstatusen i lagersystemet. Uten en slik avtale kan to systemer overskrive hverandre, og ingen vet hvilken verdi som stemmer. Kan en opplysning endres flere steder, for eksempel når kunden selv retter adressen i en portal, må det være avtalt hvilken endring som gjelder. ### En skriftlig avtale om formatet Skriv ned hvilke felt som sendes, hva de betyr og hvilke verdier som er lov. «Dato» kan bety bestillingsdato eller leveringsdato, og «pris» kan være med eller uten mva. Slike misforståelser skaper mange av feilene, også når teknikken virker. ### Feil er planlagt, ikke overraskende Nettverk faller ut, og systemer er nede for vedlikehold. En god integrasjon prøver på nytt, legger meldinger i kø i stedet for å miste dem, og tåler at samme melding kommer to ganger. Det siste kalles idempotens: at flere like forespørsler har samme virkning som én \[1\]. Uten det kan et nytt forsøk gi dobbel ordre eller dobbel faktura. > **Hypotetisk eksempel: Ordren som ble registrert to ganger** > > Nettbutikken sender en ordre til regnskapssystemet. Svaret kommer ikke fram på grunn av et kort brudd, så nettbutikken prøver igjen. Uten en fast ordre-ID som regnskapssystemet kjenner igjen, blir ordren registrert to ganger. Med en slik ID ser mottakeren at ordren allerede finnes, og ignorerer gjentaket. ### Noen merker når det stopper En integrasjon som feiler i det stille, er verre enn en som feiler høylytt. Sett opp varsel når meldinger blir liggende, når feilene øker eller når det ikke har kommet data på en stund. Bestem også hvem som får varselet, og hva de skal gjøre. ### Tilgangen er så smal som mulig Integrasjonen bør bare få lese og skrive det den trenger. Nøkler og passord skal lagres trygt og kunne byttes. OWASP, et åpent fagmiljø for programvaresikkerhet, har en egen liste over de mest kritiske sikkerhetsrisikoene i API-er, grensesnittene systemer bruker for å snakke sammen. Feil i tilgangskontroll står øverst, og for lite kontroll av data fra andres API-er er også med \[2\]. ### Endringer er forventet Leverandører oppdaterer systemene sine. Bruk versjonerte API-er der leverandøren tilbyr det, følg med på varsler om endringer, og ha tester som viser om koblingen fortsatt virker. Hold også oversikt over hvilke integrasjoner som finnes. Glemte koblinger står også på OWASP-listen \[2\]. ### Noen eier den, og det er skrevet ned Hvem retter feil? Hvem godkjenner endringer? Hvor står det hvordan koblingen virker? Når den som satte den opp, slutter, bør ikke integrasjonen bli et mysterium. Går personopplysninger gjennom en ekstern leverandør, trengs normalt også en databehandleravtale \[3\]. ## Avveininger - **Ferdig kobling eller egenutviklet:** Mange systemer har ferdige koblinger. De er raske å ta i bruk, men gjør bare det leverandøren har bestemt. En egenutviklet integrasjon kan tilpasses, men må vedlikeholdes. - **Med en gang eller samlet:** Ikke alt må skje i sanntid. Lagerstatus kan trenge oppdatering ofte, mens regnskapsbilag gjerne kan sendes samlet én gang i døgnet. Samlet overføring er ofte enklere å kontrollere. - **Direkte eller via et mellomledd:** Mange direkte koblinger mellom to og to systemer blir fort uoversiktlige. Et mellomledd som samler integrasjonene, gir bedre oversikt, men er ett system til å drifte. ## Sjekkliste Bruk listen før dere bestiller, bygger eller overtar en integrasjon: - Vi vet hvilket system som eier hver opplysning. - Feltene og betydningen deres er skrevet ned. - Integrasjonen tåler at samme melding kommer to ganger. - Meldinger som feiler, blir liggende i kø og kan sendes på nytt. - Noen får varsel når den stopper, og vet hva de skal gjøre. - Tilgangen er begrenset til det integrasjonen trenger. - Nøkler lagres trygt og kan byttes. - Vi har oversikt over alle integrasjoner og hvem som eier dem. - Databehandleravtale er på plass der personopplysninger behandles av en leverandør. ## Kilder Sist vurdert 25. oktober 2026. - [IETF RFC 9110 «HTTP Semantics», avsnitt 9.2.2 Idempotent Methods]() - [OWASP: «API Security Top 10 – 2023»]() - [Datatilsynet: «Hva må en databehandleravtale inneholde?»]() ## Les videre - [AI i eksisterende systemer](): Systemene blir stående. Det som er nytt, er koblingen mellom dem og forslaget som kommer der de ansatte jobber. - [Modernisering](): Systemet kan arbeidet deres, men hver endring tar tid og få kjenner det godt. Vi hjelper dere å bygge videre, ett trygt steg om gangen. - [Fra idé til nyttig kundeportal](): En kundeportal er nyttig når den løser noe kundene ellers må ringe, sende e-post eller vente på. Denne guiden går fra idé til første versjon i fem steg, med spørsmål, eksempler og en sjekkliste for tilgang, data og universell utforming. ## Skal dere koble sammen systemer? Start med å skrive ned hvilke opplysninger som skal flyttes, og hvilket system som eier dem. Det gjør resten av arbeidet mye enklere. - [Systemintegrasjoner]()