Parprogrammering er en teknikk i programvareutvikling hvor to programmerere jobber sammen på én maskin eller editor for å skrive kode. Dette er en velkjent smidig metodikk som kanskje ikke blir brukt så ofte som det burde. Tradisjonelt har det vært vanlig at den ene parten skriver koden mens den andre parten overvåker og tenker høyt, og at rollene byttes på jevnlig. Nå til dags finnes det verktøy som kan gjøre denne prosessen enklere, slik at flere kan redigere samtidig. Dette gjør også at rollene er mindre definerte, i og med at «rollebyttet» skjer mye hyppigere. Det er litt uenighet i hvilke tilfeller parprogrammering skal brukes. I dette blogginnlegget tar jeg for meg noen fordeler og ulemper ved bruk av denne teknikken.  

Fordeler ved parprogrammering:

Deling av kunnskap
Det jeg personlig mener er det viktigste punktet i parprogrammering er deling av teknisk kunnskap. Å observere og samhandle med andre i en jobb vil naturlig gi god innsikt i andres arbeidsmetoder, problemløsningsstrategier, snarveier og generell teknisk kunnskap.

Kanskje enda viktigere er delingen av domenekunnskap. Det er naturlig at to som parprogrammerer sammen har litt ulik kunnskap man tar i bruk i selve prosjektet. Mye av gevinsten ligger ikke bare i deling av hva man kan fra før, men det at flere enn én person får kunnskap om den nye koden som produseres. Flere i teamet vil ha kjennskap til mange deler av kodebasen. Dette vil gjøre det enklere i fremtiden hvis man skal håndtere koden, om det så skulle være en ny integrasjon, erstatning, feil eller endringer. Dette øker fleksibiliteten i hvem som kan jobbe med hva, og man er ikke avhengig av den ene personen som kanskje er syk, på ferie eller som har sluttet i teamet. Det blir også lettere å diskutere og sparre med noen dersom man skal jobbe med koden senere.  

Særlig nyttig er kunnskapsdelingen for dem som er nye i teamet eller i jobben. Dette gjelder teknisk kunnskap, men også særlig deling av domenekunnskap. Jeg tror et resultat av dette vil være en mye raskere onboardingsprosess. Den nyansatte får god innsikt i hvordan teamet jobber, hvilke tekniske løsninger som brukes og det blir lavere terskel for å stille spørsmål. Av egen erfaring er det lettere å få oversikt når man begynner å jobbe, lete og skrive i kodebasen. Å kun få en teoretisk innføring i prosjektet i form av powerpoint-presentasjoner eller lenker til sider på Wiki kan fort bli mye abstrakt informasjon når man er ny. Jeg tror tiden man bruker på å sitte med en som er ny i teamet vil være godt tjent inn senere.  

Standardisering og kodekvalitet
Tett samarbeid fører til at man utvikler en felles forståelse og praksis. Kodebasen vil være mer lettleselig da begge partene som deltar i produksjonen skal ha det klart for seg og man kontinuerlig tilpasser så partneren forstår. Ved å rotere partnere i forskjellige oppgaver vil man alltid kunne føre best praksis videre og alle vil lære litt av hverandre. 

Det at noen overvåker koden som skrives vil øke kodekvaliteten betraktelig. Dette kan også føre til at testfasen blir enklere, da feil vil oppdages tidligere. En studie fra NASA (1) fant at koden som ble skrevet under parprogrammering var mer lettleselig og bestod av omtrent halvparten så mange linjer som koden som ble skrevet uten parprogrammering. Dette skyldes effekten av kontinuerlig refaktorering og kodegjennomgang som naturlig oppstår når man er to.  

Sosialt samspill
Parprogrammeringen kan fremme bedre kommunikasjon mellom utviklerne i teamet. Særlig med mye hjemmekontor vil det sette terskelen lavere for å ta kontakt. Det sosiale aspektet er viktig for mange i arbeidet. I jobben som utvikler hører det med at man sitter mye for seg selv i egne tanker. Det er velkjent at sosial interaksjon er viktig for psyken og velvære. Det er også studier som viser direkte korrelasjon mellom sosial interaksjon og et teams ytelse (2). Sterkere relasjoner og bedre kjennskap til medarbeideres styrker og svakheter gjør det lettere å samarbeide og løse problemer. 

Økt fokus
Samarbeid i parprogrammering kan bidra til økt fokus. Når man diskuterer og løser et problem aktivt sammen er man ofte mer engasjert. Særlig i hjemmekontormiljøer tror jeg dette kan hjelpe til å redusere distraksjoner. Når man jobber tett med noen er det mindre sannsynlig at man blir fristet til å sjekke nyheter, lyden som plinget på telefonen eller e-posten som du kanskje ikke trengte å svare på akkurat nå.

Ulemper ved Parprogrammering:

Lavere produktivitet
Parprogrammering kan redusere produktiviteten målt i linjer kode produsert per time. Dette gjelder i stor grad på kort sikt, da det er mer tidkrevende diskusjoner, forklaringer og refaktoreringer. I situasjoner hvor rask koding og utrulling er kritisk, kan det være langt mer effektivt å jobbe alene, til tross for at koden sannsynligvis vil ha lavere kvalitet. 

Begrenset selvstendig tenkning
Det kan være at man begrenser seg selv når noen andre sitter og ser på, som kanskje har mer erfaring. En mer erfaren utvikler kan fort ta for mye kontroll og bestemme ting uten at den andre parten får tid til å tenke seg om. Dette kan hemme personlige problemløsningsevner. Personlig lærer jeg mye av å stange på et problem til jeg finner ut av det selv. Dette gir ofte en dypere forståelse av hvorfor ting fungerer som det gjør, enn at man bare vet at noe fungerer. Det er viktig å gi begge parter tid til å tenke og bidra, slik at man kan lære og vokse. Dette er ikke alltid like lett.

Mentalt krevende
Å jobbe tett med en annen person krever konstant fokus og kommunikasjon, noe som kan være mer mentalt slitsomt enn å jobbe alene. Folk trenger ulik tid til å prosessere informasjon. Konstant prat, høyt fokus og forklaringer kan være krevende, og kan føre til kortere utholdenhet. 

Tidskoordinering
Det kan i tillegg være utfordrende å synkronisere tidsplaner, spesielt når utviklere har ulike møter, private forpliktelser eller jobber på forskjellige prosjekter og tider på dagen. Dette kan føre til ineffektivitet og vanskeligheter med å finne passende tidspunkter for parprogrammering. Det kan også være viktig å ha noe annet å kunne jobbe med mellom øktene. Dessverre kan det fort bli sporadisk og ujevn tidsfordeling på de andre oppgavene du har påtatt deg. Om du for eksempel er midt i et prosjekt hvor du har parprogrammert og partneren blir syk i to dager, kan det være du må finne noe annet å gjøre. Når partneren din kommer tilbake har du da to prosjekter du er halvveis i, og må sette soloprosjektet på vent igjen. Slike koordineringsproblemer kan gjøre parprogrammering vanskelig i større skala. 

Ikke feilfritt
Selv om parprogrammering kan fjerne mange feil og heve kodekvaliteten, kan det også skape en falsk trygghet. Det er fort gjort å bli mindre kritisk til koden når man vet at den er sett over av en annen underveis. Hvis ikke partneren/observatøren har sagt noe, så stoler man kanskje på at alt er riktig. I motsetning til hvis man står ansvarlig for koden helt alene, hvor man kanskje har mindre tiltro til at alt er OK. Parprogrammering brukes i noen tilfeller som en erstatning for kodegjennomgang, men uansett hvor mange som har utviklet noe sammen tror jeg at det alltid er lurt å ha en kodegjennomgang med eksterne ferske øyne. 

Konklusjon  

Parprogrammering har både betydelige fordeler og ulemper. Det fremmer kunnskapsdeling, bedre kodekvalitet og samarbeid, men kan også være mentalt krevende og redusere produktiviteten på kort sikt. For å lykkes med parprogrammering er det viktig med god planlegging og tilrettelegging. Det viktigste er å se på det som et verktøy, ikke en «be-all end-all» universalløsning som skal tvinges gjennom i hver kodeblokk som skal produseres. Jeg tror tre gode steder å bruke parprogrammering er i produksjon av nye komponenter, i opplæring og ved endring av eksisterende komponenter hvor den ene parten ikke er kjent med domenet. Hvis man klarer å bruke parprogrammering der det er hensiktsmessig tror jeg et man kan oppnå et mer effektivt og kunnskapsrikt team. Jeg tror det er viktig å legge parprogrammeringen til sesjoner som ikke er for lange, for å unngå tapt fokus og gi rom for egen tenking.  

Men ellers er mitt svar ja. To hoder skrive bedre kode(r).  

 

(1) https://fun3d.larc.nasa.gov/papers/exploring_xp.pdf
(2) https://mpra.ub.uni-muenchen.de/117042/1/20230412WP.pdf 

Og bør du egentlig bry deg om forretningsregler hvis du er jurist eller jusprofessor som er opptatt av rettssikkerhet i automatiserte løsninger? Ja, mener jeg.  

Regler i lover og forskrifter er ofte upresise og mangelfulle og/eller åpner for at en virksomhet må ta noen valg om hvordan den vil praktisere reglene i sin forretningsvirksomhet. Min påstand er at forretningen (både offentlig forvaltning og private virksomheter) bør bruke konseptet forretningsregler til å dokumentere sin fortolkning og implementering av rettsreglene før reglene automatiseres i et IT-system. 

En forretningsregel er en regel som er praktiserbar og som er under forretningens styring. Regler i lover, forskrifter og styringsdokumenter fra myndighetene blir til forretningsregler i kraft av å bli fortolket og iverksatt i virksomheten. 

Men la oss begynne med begrepet rettsregel. Overraskende mange jusprofessorer har skrevet bøker om rettskildelære og innføring i juridiske emner uten å gjøre et forsøk på å definere begrepet rettsregel. Jeg mener at Erik Boe engang sa, eller skrev, noe i retning av:  

“en rettsregel er en regel som gir en rett som rettighetshaveren kan få fullbyrdet ved hjelp av rettsapparatet.” 

Boe sa det sikkert bedre, men jeg legger uansett denne definisjonen til grunn i det videre. Det sentrale her er at det finnes et utvalg av rettigheter som kan tvinges realisert med hjelp fra myndighetenes rettsapparat.  

Alle forstår med en gang at frisparkreglene på en fotballbane faller utenfor. Det samme gjelder barns leggetidsregler hjemme eller “dress code” i ditt neste middagsselskap.  

Forsikringsavtalen din om innbo kan imidlertid gi deg en rett til erstatning som du (gitt at vilkårene er oppfylt) kan få en dom på fra en domstol – som altså er en del av rettsapparatet. Forpliktelser vi tar på oss når vi inngår en avtale blir altså rettsregler med “min” definisjon.

Hva så med forretningsregler? Til forskjell fra rettsregler finnes det en lang rekke ulike definisjoner på hva en forretningsregel er. For anledningen bruker jeg definisjonen fra den åpne internasjonale standarden “Semantic of Businesss Vocabulary and Rules (SBVR)” utgitt av Object Management Group (OMG). 

 

En forretningsregel er en regel som er praktiserbar og som ligger under forretningens jurisdiksjon (1)

 

Hva skal vi forså med «forretningens jurisdiksjon»? Vi kan tenke på dette som regler som forretningen har myndighet til å endre selv. Et eksempel på en slik regel kan være åpningstider for brukere eller kunder og arbeidstid for ansatte. Likevel er det slik at diverse lover og forskrifter legger en ytre ramme for hva som vil være lovlig.   

Noen butikker skal for eksempel holde stengt på helligdager (2), og arbeidsmiljøloven (3) setter flere begrensinger for hvor mange timer en arbeidstaker skal kunne arbeide over ulike perioder.   

 

Dersom en virksomhet ønsker å opptre innenfor lovens rammer, bør forretningsreglene utformes slik at den gjør nettopp det.

 

For meg er det også et poeng at alle virksomheter har et valg. En hvilken som helst virksomhet kan velge å innføre regler og ordninger som strider med lover og regler den er underlagt. En dagligvarebutikk kan velge å holde åpent en søndag i mai for å selge hageprodukter. Virksomheter kan velge å sette opp arbeidslister og turnusordninger som strider mot begrensninger i arbeidsmiljøloven og inngåtte tariffavtaler. 

I Decisive har vi et turnussystem som gjør lovlighetssjekker på turnuslister. Automatisering av slike lovlighetssjekker krever juridisk kompetanse med tanke på å utlede rettsregelen. Juristene som utleder de ferdige tolkede reglene, bruker juridisk metode og ser på hele rettskildebildet – som for eksempel arbeidsmiljøloven, ulike tariffavtaler, etablert fast praksis og dommer med mer. 

 

For å automatisere en lovlighetssjekk bør den ferdige tolkede regelen spesifiseres på et nivå som er hensiktsmessig for både dem som kan jusen og for dem som skal implementere reglene i et IT-system. 

 

Nå er jeg over på den delen av definisjonen som går på at en forretningsregel skal være praktiserbar. Jeg tenker at praktiserbar betyr at regelen må være mulige å anvende, bruke og eventuelt utføre (4). I dette ligger det også at regelen bør være mulig å forstå for den som skal bruke regelen. 

La oss se på et konkret eksempel fra en forskrift jeg kom over som retter seg mot pensjonister med avtalefestet pensjon (AFP) som kan tenke seg å endre litt på hvor mye de jobber. Pensjonen de mottar skal endres basert på endringer i forventet inntekt. Men hvordan slår disse reglene ut for pensjonistene? Heldigvis har vi en “enkel” regel pensjonistene kan forholde seg til: 

«Dersom forventet arbeidsinntekt [min utheving] økes eller reduseres med mer enn toleransebeløpet, skal pensjonen regnes om. Selv om forventet inntekt økes eller reduseres med mindre enn toleransebeløpet, skal pensjonen likevel regnes om dersom endringen innebærer at forventet inntekt blir henholdsvis høyere eller lavere enn toleransebeløpet»  

Eksempelet er hentet fra forskrift om kombinasjon av avtalefestet pensjon for medlemmer av Statens pensjonskasse og arbeidsinntekt (pensjonsgivende inntekt), se § 4. Endringer i forventet arbeidsinntekt, andre ledd. 

Etter å ha lest bestemmelsen vet jeg egentlig ikke helt hva denne bestemmelsen betyr for en pensjonist, ei heller hvordan den skal praktiseres. Og jeg tviler på at en utvikler som skal implementere regelen i et automatisert IT system forstår det. Noe bør gjøres for å tydeliggjøre innholdet. Jeg har gjort et enkelt forsøk på å lage en forretningsregel basert på forskriftsteksten ovenfor.  

Pensjonen skal regnes om gitt at én av følgende er sant:  

• forventet arbeidsinntekt økes med mer enn toleransebeløpet
  
• forventet arbeidsinntekt reduseres med mer enn toleransebeløpet 
• forventet arbeidsinntekt øker fra et beløp lavere enn toleransebeløpet til et beløp høyere enn toleransebeløpet 
• forventet arbeidsinntekt reduseres fra et beløp høyere enn toleransebeløpet til et beløp lavere enn toleransebeløpet 

For meg spiller det egentlig ingen rolle om mitt lille forsøk representerer korrekt jus eller ikke. For meg er det viktigste at jeg har skrevet en forretningsregel som det er mulig for en utvikler å implementere i et automatisert beslutningssystem og for en jurist å ta stilling til om er riktig jus. (Fortrinnsvis en jurist med kompetanse på AFP.) 

Noen vil kanskje også legge merke til at forskriftsbestemmelsen ikke sier noe eksplisitt om hva som skal skje hvis endring/forventet inntekt er lik toleransebeløpet. Flere lesere gikk kanskje glipp av den uklarheten ved første og andre gangs gjennomlesning. La meg inkludere meg selv i den gruppen. Rettsregelen er altså ikke ferdig (uttømmende) tolket, og mitt forsøk på å lage en praktiserbar forretningsregel er dermed også mangelfull. Forretningsregelen SKAL være uttømmende beskrevet og “hullet” i forskriften må tettes etter vanlig juridisk metode. 

Uten å sette opp forretningsregler vil forretningen slite med å sikre uttømmende beskrivelser og komplett dekning for rettsreglene i sine automatiserte systemer for rettsanvendelse. 

Jeg mener det vil være en styrke for rettsikkerhet om jurister selv kan sette opp forretningsregelen slik jeg har gjort i eksempelet ovenfor. Min påstand er at bruk av forretningsregler øker tryggheten og skaper notoritet for at reglene som implementeres i rettslige beslutningssystemer representerer en ferdig tolket og korrekt rettsregel basert på juridisk metode. 

Om noen lurer, så har jeg brukt RuleSpeak til å beskrive forretningsregelen. RuleSpeak ligger på nivå to av tre når det kommer til spesifiseringsnivå. Neste nivå «ned» er en implementasjonserklæring.  

 

(1) Min oversettelse. Original: “rule that is practicable and that is under business jurisdiction,” se Semantics of Business Vocabulary and Business Rules, v1.5, page 98.
(2) Se helligdagsfredloven § 5. Salg fra faste utsalgssteder
(3) Se arbeidsmiljøloven § 10-8. Daglig og ukentlig arbeidsfri
(4) “Able to be done or put into practice successfully; able to be used, useful,” se Semantics of Business Vocabulary and Business Rules, v1.5 page 99.

Innledning 

SMARTS er et beslutningsstyringssystem (Decision Management System, DMS) utviklet av Sparkling Logic. Systemet er designet for å optimalisere og automatisere beslutningsprosesser innenfor organisasjoner ved å tillate rask implementering, testing og endring av kompleks beslutningslogikk. I denne bloggposten bruker jeg SMARTS som eksempel, men teksten vil i stor grad kunne være relevant om man vurderer andre systemer også. I den første delen av innlegget vil jeg presentere noen nøkkelegenskaper og fordeler ved bruk av SMARTS, før jeg lenger ned beskriver sentrale prinsipper for implementering av beslutninger.   

Her er noen nøkkelegenskaper og fordeler ved å bruke SMARTS: 

Sentralisert beslutningslogikk 

SMARTS hjelper organisasjoner med å sentralisere beslutningslogikken, noe som forenkler vedlikehold og oppdatering. Dette er spesielt nyttig i miljøer hvor beslutningsreglene endres ofte som respons på nye forretningskrav eller ekstern regulering fra f.eks. Stortinget eller et departement. 

Tilgjengelighet for ikke-tekniske brukere 

En av de mest fremtredende egenskapene til SMARTS er hvor tilgjengelig systemet er for ikke-teknisk personell. Plattformen tilbyr et brukervennlig grensesnitt for regelutforming, noe som lar både forretningsanalytikere, regeladministratorer, og andre ikke-tekniske roller bidra til utvikling og vedlikehold av beslutningslogikken uten dyptgående programmeringskunnskap. Ansatte med disse rollene får større eierskap til løsningen når de kan jobbe i den selv. Dette bidrar også til større trygghet i at man forvalter regelverket riktig og at automatikken fatter riktige beslutninger. 

Fleksibilitet og skalerbarhet 

SMARTS er bygget for å være fleksibelt og kan skaleres for å møte behovene til både små og store organisasjoner. Systemet kan distribueres i skyen (på plattformer som AWS, Azure, GCP, OpenShift) eller on-premise, avhengig av organisasjonens preferanser og krav til datasikkerhet. 

Avanserte analysefunksjoner 

SMARTS inneholder avanserte analysefunksjoner og simuleringsverktøy som lar brukere teste og evaluere beslutningslogikken før den settes i produksjon. Dette bidrar til å redusere risikoen og øke tilliten til beslutningene som systemet genererer. Øystein Grøndahl har tidligere skrevet om mulighetene for å vurdere konsekvenser av regelendringer, se A-B testing i SMARTS: Del 1 og A-B testing i SMARTS: Del 2.

Integrasjon med moderne teknologier 

Med støtte for HTTP APIer og tilgang til et Software Development Kit (SDK), kan SMARTS enkelt integreres med eksisterende IT-infrastruktur og applikasjoner. Dette sikrer en sømløs flyt av data og beslutninger gjennom organisasjonens økosystem.  

Sikkerhet og compliance 

Sikkerhet og compliance er kritiske aspekter for alle beslutningssystemer. SMARTS støtter sikkerhetsstandarder og autentiseringsprotokoller for å sikre dataintegritet og tilgangskontroll, samt evnen til å implementere zero trust-prinsipper gjennom bruk av kortlivede tokens. SMARTS lagrer SMARTS aldri data, heller ikke når reglene blir kjørt. 

 

Prinsipper for implementasjon av beslutninger 

Etter å ha brukt SMARTS i flere prosjekter er det noen sentrale  prinsipper det er lurt å tenke på når man implementerer beslutningstjenester. Disse prinsippene sikrer at beslutningstjenestene er robuste, vedlikeholdbare og lett integrerbare i ulike forretningsprosesser. Prinsippene kan også benyttes når man velger å implementere regler i programmeringsspråkene som en virksomhet benytter til vanlig, dette kan typisk være Java, C#, Kotlin eller Python. 

Figuren nedenfor viser et mulig eksempel på hvordan SMARTS kan integreres i en løsning:

 

Beslutninger bør være tilstandsløse 

Beslutninger bør ikke håndtere eller initiere oppdateringer av andre objekter eller ressurser. Ansvaret for slike oppdateringer bør ligge hos den prosessen som benytter resultatet av beslutningen. Dette forenkler beslutningstjenestene og sikrer at de utelukkende er dedikert til beslutningstaking. 

Beslutningstjenester bør være uavhengige av prosesser og systemer 

Ved å designe beslutningstjenester som er uavhengige av spesifikke prosesser og systemer, øker potensialet for å kunne gjenbruke tjenestene på tvers av ulike deler av organisasjonen. Dette fører til at man også støtter sentralisering av regelverket, noe som fører til likebehandling og lettere vedlikehold og oppdatering av regler. 

Bruk gjenkjennelige begreper 

Beslutningene bør implementeres ved hjelp av begreper og terminologier som er lett gjenkjennelige og direkte avledet fra regelspesifikasjonen og den tilhørende faktamodellen. Dette styrker forståelsen og overholdelsen av reglene gjennom hele organisasjonen. 

Det finnes flere initiativ for å beskrive beslutninger og forretningsregler på en strukturert måte. Formålet er både å standardisere måten regler beskrives på, samtidig som man også muliggjør verktøystøtte. Her er noen lenker som kan være av interesse: 

• https://www.decisionmanagementsolutions.com/wp-content/uploads/2014/11/Manifesto-White-Paper-October-7.pdf 
• https://decisionmanagementsolutions.com/wp-content/uploads/2019/10/The-Decision-Management-Manifesto-October-6-2019-Norwegian.pdf 
• https://en.wikipedia.org/wiki/Decision_Model_and_Notation  
• https://en.wikipedia.org/wiki/Semantics_of_Business_Vocabulary_and_Business_Rules  
• https://www.rulespeak.com/no/ 

Modellbasert input og output 

Input og output for beslutninger kan integreres med modeller som allerede er i bruk i organisasjonen. Dette bidrar til enkel integrasjon og dataflyt. 

Det er nødvendig å etablere en klar og pålitelig mappingprosess mellom de eksisterende modellene og den interne faktamodellen som beslutningstjenesten bruker. Denne mappingen bør gjøres i selve beslutningen (altså før og etter selve regelevalueringen skjer). 

Dokumentasjon og vedlikehold 

Effektiv dokumentasjon av beslutningslogikken og hvordan denne er implementert er kritisk for vedlikehold og fremtidige revisjoner. Dette inkluderer regeldokumentasjon, endringshistorikk og systemdokumentasjon. 

Testing og validering 

Systematisk testing og validering av beslutningstjenester er essensielt for å sikre at de fungerer som forventet under ulike scenarier. Dette inkluderer enhetstesting, integrasjonstesting og ende-til-ende testing. 

 

Oppsummering 

Samlet sett tilbyr SMARTS en robust, fleksibel og brukervennlig plattform for beslutningsstyring som kan tilpasses en rekke brukstilfeller, fra finansielle tjenester, detaljhandel, og mer. Og ikke minst for offentlig forvaltning hvor lovverk og forskrifter er grunnleggende i mange av systemene. SMARTS evne til å gjøre beslutninger tilgjengelig for ikke-teknisk personell, samtidig som systemet opprettholder høye standarder for sikkerhet og compliance, gjør det til en verdifull ressurs for enhver organisasjon som ser etter å optimalisere sine beslutningsprosesser.

Ved å følge prinsippene for implementering av beslutninger som jeg har beskrevet ovenfor, kan organisasjoner utvikle effektive og pålitelige beslutningsstyringssystemer som er både robuste og fleksible nok til å møte de stadig skiftende kravene i en dynamisk forretningsverden.

I mitt forrige innlegg skrev jeg om koblinger i programvare, hva de egentlig er og hvilke ulemper og fordeler de gir. I dette innlegget ser jeg videre på ulempene koblinger gir, og beskriver en modell for å vurdere hvor store disse er. Modellen er hentet fra Vlad Khononov sin presentasjon og kommende bok, Balancing Coupling in Software Design. 

I modellen klassifiseres koblinger i tre dimensjoner: styrke, avstand og endringstakt. Nedenfor beskrives disse dimensjonene, samt hvordan de kan brukes for å finne ut om ulempene med en kobling er store eller små.

Styrke

Styrken i en kobling mellom to moduler av programvare følger av hvilken av de fire beskrivelsene nedenfor som beskriver koblingen best. Modul kan her bety alt fra noe så lite som en metode i en klasse, til så store ting som hele IT-løsninger. 

Inngripende kobling (intrusive coupling) 

Dette er den sterkeste typen kobling. Her har koblingen gjort seg avhengig av interne detaljer i implementasjonen, bruker private funksjoner eller tilsvarende. Koblingen fra modul K til modul S bruker altså deler av modul S som det ikke er ment at noen andre skal bruke. Da er det stor fare for at det kan skje endringer i modul S som skaper store problemer for modul K. 

Funksjonell kobling 

Her har de to modulene fått en tett funksjonell kobling, altså at en funksjonell endring i en av modulene krever at den andre modulen også endrer sin funksjonalitet. Dette er et symptom på feil inndeling i moduler (low cohesion), og er en ganske sterk kobling. 

Modell-kobling 

I motsetning til en funksjonell kobling, er koblingen her bare mot datamodellen. Dette er en svakere kobling enn den funksjonelle, og kun endringer i selve datamodellen i den ene modulen kan medføre krav til endring i den andre modulen. Like fullt er datamodellen en svært sentral del av en modul, og det at andre moduler gjør seg avhengig av detaljer i den, vil gjøre det mer tungvint/risikabelt å gjøre endringer i modellen. 

Kontrakts-kobling 

I en kontrakts-kobling er det laget en egen modell, ofte kalt DTO, og et eget grensesnitt for integrasjon mot andre moduler. Da har modulen større frihet til å gjøre endringer i sin interne datamodell uten at det påvirker andre moduler, og tilsvarende med interne funksjoner. Dette er den svakeste koblingen av de fire. 

Avstand 

Avstanden mellom modulene som har en kobling kan ha stor praktisk betydning for hvor store ulemper koblingen gir. Avstand her er ikke fysisk avstand, men i stedet et uttrykk for hvor mye koordinering som må til for å få gjennomført endringer på begge sider av en kobling. 

Om koblingen er mellom to moduler i samme kodebase er avstanden veldig liten. Å endre i begge disse modulene samtidig er helt naturlig, og ingen koordinering trengs utover blant de som programmerer endringen.  

Hva om koblingen er mellom to mikrotjenester? Da kan det være at endringene i disse må koordineres, kanskje må det brukes expand-contract-pattern for å gjennomføre endringen på en trygg måte. Likevel er de som må koordinere arbeidet gjerne på samme team, og koordineringen er normalt ganske enkel å gjennomføre. 

Hva så om koblingen er mellom to forskjellige løsninger i samme organisasjon? Eller enda verre, mellom to løsninger i forskjellige organisasjoner? Sistnevnte kan være svært krevende å få gjennomført, og åpenbart svært mye tyngre enn å endre i moduler som ligger i samme kodebase. 

Endringstakt 

Ulempene med koblinger utløses gjerne når det skal gjøres endringer. Hvis endringer skjer svært sjeldent, kan en kobling ha både høy styrke og lang avstand, men likevel skape lite ulemper totalt sett. På samme måte kan en kobling ha både lav styrke og kort avstand, men likevel skape store problemer hvis den har veldig høy endringstakt. 

Smerten ved en kobling 

Hvordan skal så disse tre dimensjonene, styrke, avstand og endringstakt, brukes for å finne hvor uheldig en kobling er? Sentralt i Khononovs modell er følgende ligning: 

 

Smerte = Styrke * Avstand * Endringstakt 

 

Smerte er altså ulempen som koblingen gir, eller smerten ved å forvalte systemet som har koblingen. Styrke, endringstakt og avstand angis med en verdi mellom 0 og 1. Da ser vi at hvis en av faktorene er veldig nærme null, kan smerten være lav selv om de to andre faktorene er høye.  

Denne modellen synes jeg hjelper veldig med å kunne gjøre konkrete og gode vurderinger av koblinger i programvare, og slik også bidra til å avmystifisere disse koblingene som arkitekter snakker om hele tiden.

Om du vil lære mer om modellen anbefaler jeg å se en av presentasjonene til Khononov, f.eks. denne fra DDD Europe 2023. 

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.

I forrige blogginnlegg skrev Benjamin og Mohammed om hvordan de bruker generativ AI til å løse utfordringer både i arbeidslivet og ellers i hverdagen. De nevner også at bruk av kunstig intelligente systemer alltid vil innebære en viss risiko for feil og fordommer, og at man må være ekstra varsom dersom kunstig intelligens brukes til å ta avgjørelser som påvirker mennesker liv. Disse utfordringene understreker behovet for ansvarlig bruk og kontinuerlig etisk vurdering av AI-teknologi. I dette blogginnlegget tenkte jeg å skrive litt om reguleringen vi har i vente, men også litt om hvilke krav vi allerede må forholde oss til.

AI-forordningen:

Vi venter i spenning på rettslig regulering av denne teknologien. Europaparlamentet og Det europeiske råd har nå kommet til en provisorisk enighet om innholdet i The EU Artificial Intelligence Act, og det er forventet at denne forordningen vil tre i kraft i løpet av 2026. Målsettingen til forordningen er å øke bruken av menneskesentrisk og pålitelig kunstig intelligens og sikre et høyt nivå av beskyttelse for helse, sikkerhet, fundamentale rettigheter, demokrati, miljøet og rettssikkerheten fra de skadelige effektene av slike systemer. Et slikt rammeverk vil sikre at all utvikling og bruk av kunstig intelligens innenfor EU/EØS ivaretar våre lovfestede rettigheter og er i tråd med våre verdier. Forordningen har en risikobasert tilnærming og stiller krav til selve AI-systemet, men også til leverandør og bruker.

Selv om AI-forordningen tidligst vil tre i kraft i 2026 – er det ikke slik at vi avventer med å ta i bruk kunstig intelligens til forordningen er på plass. Kunstig intelligens har potensialet til å skape store gevinster i samfunnet ved å blant annet effektivisere, gi oss ny kunnskap og støtte beslutningsprosesser, og norske virksomheter er ivrige etter å ta teknologien i bruk allerede nå. Å bruke kunstig intelligens på en lovlig måte kan være utfordrende når det ikke er mye juridisk praksis på området. Heldigvis er tre av fire av årets prosjekter som er plukket ut av Datatilsynet for utforsking i den regulatoriske sandkassa prosjekter som utforsker bruken av generativ kunstig intelligens. Forhåpentligvis vil resultatene av disse prosjektene ha overføringsverdi, og sette en standard for hvordan vi kan bruke generativ kunstig intelligens.

Ikke et lovløst område:

Selv om vi per i dag ikke har lovgivning som spesifikt regulerer utvikling og bruk av kunstig intelligens, betyr ikke dette at dette er et lovløst område. Vi har flere lovverk som setter rammer for hvordan vi kan utvikle og bruke kunstig intelligens: Hvis kunstig intelligens skal brukes til å behandle personopplysninger, vil kravene i personvernforordningen gjelde. Personvernforordningen stiller blant annet krav til åpenhet – hvor den registrerte har rett til relevant informasjon om den underliggende logikken samt om betydningen og de forventede konsekvensene av en slik behandling, ved forekomsten av automatiserte avgjørelser. Dette kravet vil være vanskelig å etterleve hvis vi ikke kan forklare hvordan det kunstig intelligente systemet kommer frem til et gitt resultat.

På lik linje vil det være vanskelig å gi begrunnelser for enkeltvedtak som viser til de faktiske forholdene et vedtak bygger på etter forvaltningsloven § 25, hvis vi ikke forstår hvordan modellen fungerer, hvilke faktorer som er vektlagt i beslutningsprosessen og hvordan disse har ført til resultatet. Vi har også et diskrimineringsvern i likestillings- og diskrimineringsloven, som skal fremme likestilling og hindre diskriminering i det norske samfunnet. I og med at kunstig intelligens ofte trenes på store datasett, er det viktig å være obs på skjevheter i datagrunnlaget modellen er trent på. Historiske skjevheter eller feil i datainnsamlingen kan føre til at modellen tar avgjørelser på feil grunnlag, og dermed opptrer diskriminerende. Vi har også regler for vern av immaterielle rettigheter, slik som opphavsretten. Det kan oppstå problemstillinger knyttet til opphavsrett både i forbindelse med trening av kunstig intelligens, men også ved bruk av det materialet den kunstige intelligensen genererer.

Som påpekt ovenfor har vi allerede lovgivning som setter klare rammer for hvordan vi kan utvikle og ta i bruk kunstig intelligens, selv om disse ikke direkte adresserer de unike utfordringene knyttet til kunstig intelligente systemer. Vi er spente på å følge denne utviklingen videre, både når det kommer til gevinstene kunstig intelligens kan gi, men også utviklingen på det rettslige området.

Etter et godt år som nyutdannede IT-konsulenter støter vi stadig på utfordringer i både arbeidslivet og i hverdagen, som vi har brukt generativ AI til å løse eller forbedre. Bli med oss på en reise i hva vi bruker AI til. 

AI for Kodeforbedring 

Vi har utforsket hvordan generativ AI kan optimalisere kode for økt lesbarhet og effektivitet. Nedenfor viser vi et Kotlin-kodeeksempel som kan forbedres, etterfulgt av en AI-optimalisert versjon. Forbedringene inkluderer mer intuitive funksjonsnavn, bedre parameter-navngivning, og håndtering av spesialtilfeller. 

La oss starte med den opprinnelige koden:

Kodeeksempelet ovenfor er et grunnleggende eksempel som tar inn en liste med heltall og regner ut gjennomsnittet av disse. For å gjøre koden mer lettlest kan vi gjøre små endringer. Vi lot AI hjelpe oss med forbedringene: 

I denne versjonen har funksjonsnavnet blitt gjort mer forståelig, parameteren har fått et mer beskrivende navn, og det er lagt til en sjekk for å håndtere et spesialtilfelle. Dette eksempelet viser hvordan koden kan gjøres mer lesbar og lett å forstå. 

Eksempelet vi bruker her er grunnleggende, men metodikken er også anvendelig på mer komplekse kodeutfordringer. 

Fremtidens søkemotor? 

Som utviklere kan vi ofte tilbringe betydelig tid på plattformer som Stack Overflow eller lignende steder i jakten på eksempler og løsninger på våre problemstillinger. Prosessen med å søke gjennom Google for å finne relevante tråder kan være tidkrevende, og det er ikke alltid lett å finne oppdatert informasjon i eldre dokumentasjon eller tråder. Med hjelp av ChatGPT kan prosessen forenkles. Ved å tilby raske og presise svar, reduseres behovet for dyptgående søk gjennom gamle tråder. Dette kan frigjøre verdifull tid for oss og andre utviklere, så vi får mulighet til å fokusere på dagens utfordringer med mer effektivitet og nøyaktighet. 

AI i Hverdagslivet 

Overfører vi dette til hverdagen, møter vi på liknende situasjoner. Som travle konsulenter i 20-årene, med tidsklemme og et kjøleskap som av og til ser ut som et kulinarisk puslespill, har vi vendt oss til AI for hjelp. I stedet for å søke blindt etter oppskrifter, spør vi vår AI-assistent om forslag basert på det vi har tilgjengelig. 

Vi spurte AI-assistenten vår ‘Hva kan jeg lage med laks, melk, mel, egg, smør, løk og brokkoli?’ 

Svaret ble en appetittvekkende laks- og brokkoligrateng, med en trinnvis oppskrift: 

Med ingrediensene laks, melk, mel, egg, smør, løk, og brokkoli, kan du lage en deilig laks- og brokkoligrateng. Her er en enkel oppskrift: 

Laks- og Brokkoligrateng 

Ingredienser: 

• 400 g laks (fersk eller frossen) 
• 300 g brokkoli, kuttet i små buketter 
• 1 stor løk, finhakket 
• 2 ss smør 
• 2 ss hvetemel 
• 400 ml melk 
• 2 egg 
• Salt og pepper etter smak 
• En klype muskatnøtt (valgfritt) 

Fremgangsmåte: 

1. Forbered Laksen og Brokkolien: Forvarm ovnen til 180°C. Hvis du bruker frossen laks, la den tine. Kok brokkolien i lettsaltet vann i ca. 3-4 minutter til den er al dente. Tøm av vannet og sett til side. 
2. Lag Hvitsausen: Smelt smør i en kjele på middels varme. Tilsett finhakket løk og stek til den er myk. Tilsett hvetemelet og rør godt. Spe gradvis med melk mens du rører, til sausen blir tykk og jevn. Kok opp, og la sausen småkoke i ca. 5 minutter. Smak til med salt, pepper og en klype muskat. 
3. Bland Inn Egg: Ta sausen av varmen. Rør inn ett egg om gangen, pass på at sausen ikke er for varm så eggene ikke koagulerer. 
4. Montering: Legg laksen i en smurt ildfast form. Fordel brokkolien rundt. Hell hvitsausen over. 
5. Stek: Stek i forvarmet ovn i ca. 20-25 minutter, eller til overflaten er gyllen og gratengen er gjennomvarm. 
6. Servering: La gratengen hvile i noen minutter før servering. Serveres varm, gjerne med et dryss av friske urter for ekstra smak. 

Nå vil jeg lage et bilde av hvordan denne retten kan se ut når den er ferdig. 

Utfordringer med AI 

Med stor makt følger også et stort ansvar. AI har mange fordeler, men det er også flere utfordringer som må tas på alvor. Overbruk av AI-systemer kan skape avhengighet av teknologi og vi kan risikere at kritisk tenkning og problemløsning blir negativt påvirket av bruken. AI-systemer behandler i tillegg store mengder data, inkludert personopplysninger. Selv om treffsikkerheten ofte er høy vil det alltid være en risiko for feil og fordommer, som man må være ekstra varsom på dersom man bruker det til avgjørelser som påvirker menneskers liv. Disse utfordringene understreker behovet for ansvarlig bruk og kontinuerlig etisk vurdering av AI-teknologi.           

Konklusjon 

Gjennom våre erfaringer med generativ AI, ser vi hvordan denne teknologien kan være en kraftfull ressurs for å løse komplekse problemstillinger og forenkle hverdagen. Samtidig minner de mulige utfordringene ved bruk av AI oss på viktigheten av en balansert og ansvarlig tilnærming til denne transformative teknologien. Ved bruk av AI er det avgjørende å ha en klar forståelse av systemets begrensninger og etiske implikasjoner for å sikre at vi drar full nytte av dens potensiale uten å gå på akkord med våre verdier og sikkerhet. 

 

Dette er innlegg 2 i en serie på 2 deler der vi skal se på hvordan vi kan bruke regelmotoren SMARTS til å vurdere konsekvensen av en eller flere endringer i forretningsreglene våre. I del 1 satte vi opp reglene for en fiktiv offentlig etat som behandler søknader om penger. I del 2 ser vi på hvordan vi kan vurdere konsekvensen av regelendringer.

Et eksempel er at en offentlig etat får spørsmål fra departementet om hvor stor innvirkning en viss regelendring politikerne vurderer vil ha på statsbudsjettet. Slike konsekvensvurderinger kan gjøres på mange måter. Her er en beskrivelse av hvordan det kan gjøres i regelmotoren SMARTS.

I dette eksemplet later vi som vi er en offentlig etat som behandler søknader om penger. La oss si at vi får et spørsmål fra departementet. Det viser seg at politikerne vurderer to regelendringer:

• Den ene er å legge til Viken fylke i listen over fylker vi godkjenner søknader fra.
• Den andre er å redusere utbetalingene fra 80 % av inntekten over 50 000 til 70 % av inntekten over 50 000.

Departementet lurer på hvordan dette vil slå ut på antall søknader som innvilges per år og totalt utbetalt beløp per år.

Vi kan legge inn de nye regelforslagene som alternative regler som vist under for beregningen:

Deretter kan vi kjøre et «experiment» der vi sammenlikner ulike konfigurasjoner av reglene. Vi kjører fire varianter av reglene og sammenlikner resultatene:

1. Dagens regler.
2. Dagens regler + ny regel for godkjente fylker.
3. Dagens regler + ny regel for beregning.
4. Begge de to nye reglene.

I SMARTS kan vi lett sammenlikne resultatene for de ulike konfigurasjonene. I bildet nedenfor sammenlikner vi resultatene for punkt 1 og 2 over.

Vi ser at det endres fra 7 avslag til 6 avslag blant våre 16 testcaser, og det medfører at totalt utbetalt beløp øker fra 2 900 800 til 3 172 000, en økning på 271 200. Blant våre 16 tester var det en søknad fra Viken, som med gamle regler ble avslått, men som med nye regler blir innvilget.

Vi kan altså se konsekvensen av den foreslåtte regelendringen på vårt sett av testcaser. For å svare på spørsmålet fra departementet kan vi gjøre en av følgende:

1. Påstå at vårt sett av testcaser er representativt for de faktiske søknadene vi får gjennom året, og gange opp med en viss faktor for at det skal tilsvare det faktiske antallet søknader gjennom året.
2. Lage et sett av testcaser som er representativt for de faktiske søknadene vi får gjennom året.
   a) Vi kan studere ekte søknader, intervjue saksbehandlere osv. og lage et sett av tester.
   b) Vi kan ta ekte søknader fra en viss periode (f.eks. 3 måneder av fjoråret, eller hele fjoråret), anonymisere de og bruke disse som testcaser.

Det er ikke lett å lage et sett av tester som er representativt for ekte søknader gjennom året. Det er heller ikke trivielt å anonymisere faktiske søknader, men det er en mulighet.

I tillegg til å lage et sett av tester som er representative for søknader vi pleier å få, må vi vurdere om søknader vi pleier å få er representative for hva vi vil få med nye regler. F.eks. kan det hende at vi får flere søknader fra Viken når vi begynner å innvilge også for dette fylket, fordi folk i dag lar være å søke fordi de vet at søknadene vil bli avslått. Det er altså sannsynlig med en større økning i utbetalt beløp enn den vi kan se på 271 200 i bildet over. Kanskje vi kan estimere basert på antallet søknader fra et tilsvarende fylke.

Verktøy som SMARTS hjelper oss med å vurdere konsekvensene av regelendringer på våre sett av testcaser, men vi må alltid tenke selv i tillegg og vurdere om det kan skje endringer som gjør at vårt sett av testcaser ikke er representativt for de søknadene vi vil få hvis regelendringen innføres. Til sammen lar dette oss svare departementet med et estimat på hvor mange søknader som vil innvilges med nye regler, og et estimat på totalt utbetalt beløp.

 

Dette er innlegg 1 i en serie på 2 der vi skal se på hvordan vi kan bruke regelmotoren SMARTS til å vurdere konsekvensen av en eller flere endringer i forretningsreglene våre. I del 1 setter vi opp reglene for en fiktiv offentlig etat som behandler søknader om penger. I del 2 ser vi på hvordan vi kan vurdere konsekvensen av regelendringer. 

I dette eksemplet later vi som vi er en offentlig etat som behandler søknader om penger. Søknadene skal innvilges hvis 

• søker er minst 18 år gammel 
• søker har inntekt på mer enn 50 000 kr per år og under 800 000 kr per år 
• søker bor i et av fylkene Vestland, Nordland, Agder eller Trøndelag. 

Når en søknad innvilges skal vi utbetale 80 % av den inntekten som overstiger 50 000 kr per år.

I bildet ovenfor ser vi at en person som er 29 år gammel med inntekt på 600 000 og som bor i Vestland fylke får innvilget søknaden, og får utbetalt 440 000. Reglene som avgjør dette kan se ut som vist i bildet nedenfor:

Vi lager til sammen 16 testcaser med ulike inputs og setter opp søylediagram som viser antall avslag, antall innvilgelser, og totalt utbetalt beløp. Vi ser at 7 av 16 søknader avslås, 9 av 16 innvilges, og totalt utbetales det 2 900 800 kr for innvilgede søknader (og 0 kr for avslåtte søknader).