Koblinger i IT-løsninger – hva er det egentlig?

15. februar 2024

Vi arkitekter snakker hele tiden om hvor viktig det er med løse koblinger i programvare. Hva betyr egentlig det? Og hva er egentlig en kobling i programvare, sånn helt konkret?

Ofte har vi en tjeneste som løsning S tilbyr, og som løsning K tar i bruk. Her er løsning S server-siden, mens løsning K er klient-siden. Løsning K sin bruk av tjenesten i løsning S har da skapt en avhengighet, eller en kobling, mellom de to løsningene.

Det følger flere ulemper med dette. Det kan være at løsning K krasjer hvis løsning S sin tjeneste går ned (en driftsmessig kobling). Eller hva om løsning S endrer på tjenesten, kanskje endres navnet på et av feltene? Vil denne endringen føre til at løsning K brått bare får feilmeldinger når den prøver å bruke tjenesten (en endringsmessig kobling)? Hvis slike problemer oppstår, har vi det som kalles harde koblinger. Et driftsavvik, eller en endring, på løsning S, slår altså veldig uheldig ut for løsning K.

Hva er så en løs kobling, som vi er så opptatt av å få til? En løs kobling gjør at endringer eller driftsavvik i løsning S ikke får store negative konsekvenser for løsning K. Hvordan går vi så frem for å få til dette?

Løsning K kan designes slik at den har en intern kø for kallene som skal gjøres til løsning S. Hvis tjenesten i løsning S går ned, blir kallene liggende på køen i løsning K, så lenge tjenesten er nede. Når tjenesten kommer opp igjen, plukkes kallene opp fra køen og gjennomføres. Konsekvensene av nedetid på tjenesten er da begrenset til å skape en forsinkelse, i stedet for at løsning S krasjer. Da er den driftsmessige koblingen gjort løsere.

For å redusere den endringsmessige koblingen kan løsning S rulle ut endringer i tjenesten sin i flere trinn. En vanlig teknikk for dette kalles expand-contract-pattern. Da skjer endringen i følgende trinn:

1: Tjenesten utvides med ny verdi, men tjenesten krever enda ikke at alle klienter sender inn den nye verdien. Dette er expand-trinnet.

2: De som bruker tjenesten legger til den nye verdien i kall de gjør til tjenesten. Dette kan gjøres når det passer klientene, kanskje dager eller uker etter at del 1 er gjort.

3: Når alle klientene har gjort endringen, endres tjenesten til å kreve at verdien legges med i alle kallene. Dette er contract-trinnet.

Hvis løsning S gjør endringer med denne metoden, har løsning K god tid til å gjøre sine endringer, og unngår dermed plutselige feil, eller krevende koordinering. Da har vi gjort den endringsmessige koblingen mye løsere.

Både utviklere og arkitekter bruker mye tid og energi på å gjøre koblinger løsere. Dette har blitt enda viktigere de senere årene, siden det nå forventes at løsninger alltid er oppe, og at endringstakten skal være høy. Dette kommer ikke uten kostnad. Å designe klienter slik at de takler nedetid på tjenester øker kompleksiteten og kostnaden ved å ta i bruk tjenester. Å bruke expand-contract-pattern for å gjøre endringer tar mer tid, og er mer komplisert, enn å bare gjøre endringer rett frem.

Vi får det kanskje til å høres ut som koblinger er noe negativt som må unngås, men det stemmer jo ikke. En løsning har faktisk ingen verdi uten koblinger. Tenk om løsning K var en løsning for å beregne og utbetale penger igjen på skatten, og at løsning S var bankens løsning for å overføre penger. Løsning K hadde ikke vært mye verdt, hvis den ikke hadde noen kontakt med bankens løsning. Forretningsverdien til løsning K leveres faktisk gjennom koblingen til bankens løsning S.

Koblinger er altså en naturlig og nødvendig del av IT-løsninger for at de skal skape verdi. Samtidig må vi som utvikler løsninger også bygge disse koblingene på en måte som skaper mest mulig robuste og endringsvillige løsninger, selv om det kan være krevende å få til.