Digitaliseringens treenighet

En liten kikk på forvaltningsinformatisk metode
desember 12, 2024

Introduksjon

Som et siste blogginnlegg før jul tenkte vi å skrive litt om digitalisering, og hvordan endringer i forskjellige dimensjoner henger sammen og påvirker hverandre. Begge forfatterne av dette blogginnlegget er utdannet forvaltningsinformatikere, hvor tverrfaglighet ligger i kjernen av faget. Forvaltningsinformatikk er en tverrfaglig utdanning som kombinerer juridiske, informatiske og samfunnsfaglige innfallsvinkler. Denne kompetansen er nyttig for å forstå hvordan IKT, organisasjoner og mennesker spiller sammen og påvirker hverandre, hvordan teknologi påvirker samfunnet, og hvilke juridiske konsekvenser utnyttelse av teknolog kan gi.  

I og med at vi er over gjennomsnittet opptatt av hvordan digitalisering påvirker samfunnet har vi sett frem til og satt pris på den nye digitaliseringsstrategien, «Fremtidens digitale Norge», som virkelig setter digitalisering på dagsordenen. I digitaliseringsstrategien står det blant annet om hvordan forskjellige drivkrefter i samfunnet påvirker hvordan samfunnet digitaliseres. Videre beskriver den hvordan drivkreftene og trender beveger seg raskt og at alle land bør arbeide med innsikt om fremtiden. Derfor tenkte vi at det kan være nyttig å diskutere en enkel metode for å analysere noen endringer og hvordan disse påvirker digitalisering.

Tre dimensjoner i endring

Begrepet digitalisering kan brukes om konvertering av analoge til digitale data, men også om innføring av digital teknologi som effektiviserer prosesser og endrer hverdagslivet. Kunstig intelligens er et eksempel på en teknologi som mange offentlige virksomheter nå inkorporerer i sine arbeidsprosesser, og som har potensialet til å effektivisere enkelte av disse prosessene betydelig. Samtidig er det viktig å huske på at teknologisk endring, slik som innføring av ny teknologi, ikke skjer i et vakuum – og at denne endringen vil føre til endringer i andre dimensjoner. Nedenfor har vi illustrert dette i en forvaltningsinformatisk figur, som viser hvordan teknologisk endring påvirker (eller fører til) både rettslig- og organisatorisk endring.     

Teknologisk endring 

Skjer det endring i teknologien, ved eksempelvis innføring av kunstig intelligens, vil dette også føre til rettslig og organisatorisk endring. Den nye teknologien påvirker samfunnet på flere måter, for eksempel ved at den kan utgjøre en risiko for individets rettigheter og friheter og at lovgiver dermed ser behov for å regulere den nye teknologien og lager en lov med mål om å gjøre nettopp dette. Dette har skjedd i forhold til kunstig intelligens med KI-forordningen, som skal sikre at KI-systemer som brukes innenfor EU er trygge, og at de respekterer våre grunnleggende rettigheter og verdier.  

Videre vil ny teknologi som KI kunne ha stor innvirkning på organiseringen av samfunnet. Vi ser allerede nå en bekymring fra enkelte yrkesgrupper når det kommer til om jobber vil gå tapt til forsøk på å automatisere stillinger. Per i dag er dette særlig relevant for kreative oppgaver som involverer å lage bilder eller skrive tekster. En endring som dette vil igjen kunne kreve vern for visse yrkesgrupper i lov, eller evt. subsidier for å beskytte ønsket kompetanse.  

Rettslig endring

En rettslig endring kommer sjeldent ut av det blå. Innføring av nye lover, eller endring i eksisterende lov og forskrift vil ofte skje som et resultat av endring i teknologi eller organisering. Selv om rettslig endring ofte trigges av teknologisk eller organisatorisk endring, vil innføring av nye lover også ha effekt på både teknologi og organisering når loven trer i kraft. Bruker vi den ovenfornevnte KI-forordningen som eksempel kommer denne som følge av bekymringer for konsekvensene KI vil kunne ha for våre europeiske grunnleggende rettigheter og verdier, og er med det lagt opp slik at den regulerer hvilke produkter som er akseptable på markedet og hva som skal til for at det enkelte produkt er akseptabelt. Forordningen vil ha potensiale til å styre produktutviklingen og kvalitetssikringen av KI-produkter, da vi antar virksomheter fremdeles ønsker å kunne selge sine produkter på det europeiske markedet.  

På grunn av kravene som stilles til systemene som treffes av KI-forordningen vil mange virksomheter se behov for å skaffe kompetanse om KI-forordningen og hvordan å sørge for etterlevelse. Dette kan fort føre til at nye roller blir opprettet for å sikre etterlevelse. På nasjonalt plan stiller KI-forordningen også krav til at medlemslandene skal ha et KI-tilsyn, akkrediteringsorganer for sertifiseringsorganer og at det skal opprettes minst en sandkasse for KI i hvert land. Alt dette er eksempler på hvordan en rettslig endring vil føre til organisatoriske endringer. Et annet eksempel er krav om personvernombud for enkelte virksomheter etter GDPR, som førte til at mange virksomheter måtte opprette en ny rolle og ny organisering for enkelte oppgaver.      

Organisatorisk endring 

Ved innføring av ny teknologi eller ved en rettslig endring, vil det også skje en organisatorisk endring. Dette kan både være at det opprettes nye roller slik vi har nevnt ovenfor, men det kan også være at interne prosesser må omorganiseres eller endres. Oppgaver som tidligere ble utført manuelt kan effektiviseres eller automatiseres, noe som kan føre til at enkelte roller blir overflødige. Rettslige endringer som ikrafttredelse av KI-forordningen fører også til en lovpålagt plikt til opplæring av ansatte.  

Bruk av hjemmekontor er et eksempel på en organisatorisk endring som har ført til tekniske endringer, ved at videokonferanseteknologi har blitt standard for alle virksomheter og kvaliteten på dette har blitt langt bedre enn før pandemien. Videre førte dette til behov for regelverksendringer som gjør at offentlige virksomheter må avtale med ansatte om bruk av hjemmekontor.  

Avslutning  

Digitalisering er et evig spill av påvirkning mellom disse dimensjonene (Og flere! Her har vi for eksempel ikke trukket inn økonomiske endringer). Det er viktig å analysere enhver kommende endring i en enkelt dimensjon, og avklare hvordan dette vil påvirke de andre dimensjonene for å kunne planlegge den videre digitaliseringen på en god måte.  

Vi mener at verken teknisk- rettslig eller organisatorisk endring kan skje i et vakuum: Ha et helhetlig perspektiv – se alt i sammenheng! 

 

Marianne Bang

Rådgiver

marianne.bang@decisive.no

Pernille Nilsen

Rådgiver

pernille.nilsen@decisive.no

Prinsipper, metoder og verktøy for å generere tekster: Del 2

november 28, 2024

Automatisk generering av brev 

Dette er del 2 av 2 om å generere tekster. Dette bygger videre på del 1, så for å få helheten anbefaler jeg at du leser det innlegget først.

Helt grunnleggende skal vi generere brev på denne måten: Systemet velger riktig brevmal for situasjonen, bruker informasjon fra saksbehandlingen til å vurdere om enkelte fraser skal inkluderes i eller eksluderes fra brevet i denne saken, og fyller inn flettefelter for å tilpasse frasene til den konkrete saken. Til slutt kan brevet sendes ut til mottaker, enten gjennom Altinn eller via print til papir og sendes i posten. 

For å generere brev automatisk vil jeg bruke en brevmal og en dokumentmal. Brevmalen inneholder faste fraser og regler som styrer hvilke fraser som skal være med i ulike tilfeller. Dokumentmalen definerer fonter, skriftstørrelser, linjeavstand, marger, hvordan vi skriver sidetall osv. Fordelen med å ha begge er at du kan definere en dokumentmal én gang, og så kan alle som vil følge samme dokumentmal bare si at deres brevmal skal bruke en viss dokumentmal. Det går raskere å lage nye brev når du slipper å måtte finne ut av alle sånne detaljer, og brevene blir like uten at alle må anstrenge seg for å gjøre det rett. Du bare sier «denne brevmalen skal bruke standard dokumentmal», så får du organisasjonens foretrukne skriftstørrelser, fonter, osv. 

Brevmalene definerer innholdet i et brev. Du kan ha en brevmal for flere situasjoner, og styre innholdet med diverse regler. Da kan én brevmal ha tekster for å både innvilge og avslå en søknad. Men hvis det meste av innholdet for de to situasjonene er forskjellig kan det være lurt å ha to brevmaler, en for innvilgelsesbrev og en for avslagsbrev. 

En brevmal kan lages ved å ha noen faste fraser og noen fraser som bare blir med i visse tilfeller, avhengig av saksegenskaper. En brevmal kan f.eks. se slik ut: 

Dokumentmal = Standardbrev 

Søknadsbehandling/Innvilgelsesbrev/Overskrift 

Søknadsbehandling/Innvilgelsesbrev/Introduksjon 

Søknadsbehandling/Innvilgelsesbrev/Begrunnelse 

<SpesiellSak == true> Søknadsbehandling/Innvilgelsesbrev/EkstraInformasjon 

Felles/Innsynsrett 

Felles/RelevanteReglerForDetteBrevet 

Felles/KontaktOss 

Felles/Signatur 

Her har vi mange faste fraser, og en frase som er avhengig av at feltet «SpesiellSak» er «true». Altså en frase som bare blir med i noen innvilgelsesbrev. Mer om dette feltet og tilsvarende i neste kapittel. Vi har noen fraser som er spesifikke for dette innvilgelsesbrevet, og noen fraser som er felles med andre brev. Frasen Felles/RelevanteReglerForDetteBrevet vil ha ulikt innhold fra brev til brev, siden det som faktisk står i den er de lovhenvisningene som brevets fraser er knyttet til. Det er likevel en felles frase som inneholder logikken for å samle det enkelte brevs lovhenvisninger. 

Bruk av brevmalen 

Når du jobber med saksbehandling gjør du noen valg. Noen av disse valgene skal vi informere om i et brev. Noen saker er spesielle i seg selv, f.eks. på grunn av egenskaper ved søker. Hvordan skal systemet vite hvilke fraser som skal være med i et brev? Vi må definere noen regler for å velge hvilke fraser som skal være med i brevet. F.eks. kan vi ha en regel som sier «Gitt at søker er under 18 år skal tekst om mindreårige søkere inkluderes i brevet», eller «Gitt at saksbehandler valgte å krysse av for Ja i skjermbilde 4 («Er dette en spesiell sak?») så skal tekst om spesielle saker inkluderes i brevet» eller «Gitt at det er forsinkelsesrenter i saken så skal tekst om forsinkelsesrenter inkluderes i brevet». I tillegg er det forskjellige tall, navn og annet som skal inn i brevet. F.eks. søkers navn, søkers adresse, dagens forsinkelsesrentesats, dagens dato eller beløp til utbetaling. 

Jeg beskriver en måte å strukturere dette her. Jeg forutsetter at man har flere tekniske komponenter i systemet, og at brevkomponenten er en felles komponent som flere saksbehandlingskomponenter bruker. Jeg forutsetter at de generelle brevreglene ligger i brevkomponenten, mens reglene for å plukke ut de opplysningene vi ønsker å legge inn i brevet ligger i den saksbehandlingskomponenten som er nærmest på de opplysningene, og der ekspertisen på den saksbehandlingen sitter. Da må vi samle sammen informasjon om saken i saksbehandlingskomponenten og sende det til brevkomponenten. 

Vi må spesifisere regler for å plukke ut ønskede opplysninger og strukturere opplysningene på en måte som vi er enige med brevmodulen om. En måte å gjøre det på er i JSON-format, omtrent som vist her: 

    «navn»: «Per Persen», 

    «adresse»: «Gateveien 1», 

    «forsinkelsesrentesats»: 12.5, 

    «spesiellSak»: false, 

    «mindreårigSøker»: false, 

    «vedtaksdato»: «2024-10-25» 

Brevmodulen bruke dette til å velge om frasene Søknadsbehandling/Innvilgelsesbrev/Introduksjon og Søknadsbehandling/Innvilgelsesbrev/SpesiellSak skal være med i brevet, og til å fylle ut flettefelter i fraser. 

Vi må også velge språkform. Vi har alle fraser på bokmål, nynorsk og engelsk. Hvilke skal brukes til en gitt mottaker? Kanskje vi har et kunderegister eller en annen form for register der vi har ulike aktørers ønskede språkform. Da kan brevkomponenten slå opp ønsket språkform og velge riktig variant av alle fraser. Vi bør definere en regel for hva vi gjør hvis vi ikke har fraser på ønsket språkform. F.eks. om vi ønsker en feilmelding, eller å bruke den språkformen som finnes, eller å sende saken til menneskelig saksbehandler for å skrive brev manuelt. 

Avslutning 

Det er mange fordeler ved å håndtere brev og fraser som beskrevet her, men det er naturligvis noen ulemper også. Det er mye jobb for å få alt dette på plass. Det kan være en stor endring fra hvordan du skriver brev i dag, spesielt hvis det er noe saksbehandlere gjør manuelt. En slik endring krever ikke bare IT-utvikling, men også endringsledelse. Saksbehandlere kan føle at de mister kontrollen over brevene, og du må sikre at de får tillit til automatisk genererte brev. Organisasjoner av ulik størrelse og med ulike mål og rammer kan ha nytte av ulike deler av dette. En fordel er at du kan ta i bruk fraselager-tabellen for å få likere struktur og tekst i brevene selv om du ikke har noen av de tekniske komponentene for å automatisk generere brev. Jeg vil også minne om at det er mulig å bruke dette generelt til å generere tekst, ikke bare til typiske «brev». 

Det viktigste er å vurdere om du er fornøyd med måten dere kommuniserer skriftlig i din organisasjon. Hvis du ikke er fornøyd kan du begynne med å vurdere hva du ønsker å oppnå, og deretter finne egnede tiltak. Det kan være noe eller alt som er beskrevet her, eller det kan være andre tiltak og løsninger. 

Øystein Grøndahl

Rådgiver

oystein.grondahl@decisive.no

Prinsipper, metoder og verktøy for å generere tekster: Del 1

november 21, 2024

Innledning

I dette og neste blogginnlegg vil jeg skrive om prinsipper, metoder og verktøy for å generere tekster. Jeg skriver med fokus på det å sende noen et brev for å informere om noe. Det kan være et vedtak fattet i offentlig forvaltning, eller brev til bank-kunder med informasjon om nye rentesatser, eller andre ting. Dette er egentlig helt generelt, og handler om hvordan du kan generere en tekst. Om det er i A4-format som sendes som PDF eller papir, tekst i epost, sms eller annet har ikke noe å si. For enkelhets skyld tar jeg utgangspunkt i det å sende et vedtaksbrev i PDF-format for å informere om en beslutning. 

Det jeg beskriver i dette blogginnlegget er ikke noe jeg har funnet på alene. Dette er i stor grad konkrete ting som er laget i programmet Fremtidens innkreving i Skatteetaten, men det er også generelle prinsipper og metoder. Jeg skriver om dette for å informere om noe jeg synes er smart som kanskje andre kan ha nytte av. 

Helheten av det jeg beskriver vil nok være mest aktuelt for store organisasjoner, men noen deler kan være aktuelle selv for små organisasjoner. 

Prinsipper for skriftlig kommunikasjon 

Her beskriver jeg noen prinsipper som ligger til grunn for metoder og verktøy som jeg beskriver senere. Det meste kommer av hvordan Skatteetaten ønsker å kommunisere i sine brev og fremstå utad. Jeg tror det er relativt generelle prinsipper, som noen vil være enig i og andre kan være uenig i. Ulike organisasjoner kan ha ulike behov og ønsker, så du må vurdere hvilke av disse som er aktuelle for deg og din organisasjon. 

  • Innholdet skal være korrekt. Det skal være godkjent av fageksperter, fagansvarlige, jurister eller andre.
  • Innholdet skal være klarspråklig for at alle mottakere skal forstå budskapet. Det skal vurderes av noen med klarspråkskompetanse.
  • Vi skal ha lik kommunikasjon utad for å oppfattes enhetlig:

    Noe innhold skal være likt på tvers av fagområder. F.eks. hvis du har et avsnitt i slutten av brevet som sier «Har du spørsmål? Kontakt oss på denne måten: …» så skal det være likt i alle brev der du vil ha med en slik tekst.

    Innholdet skal ha felles form på tvers av fagområder. F.eks. bør vedtaksbrev fra en del av organisasjonen likne på vedtaksbrev fra en annen del av organisasjonen. Dette kan f.eks. være rekkefølgen på avsnittene «Relevante regler i dette brevet», «Har du spørsmål?» og «Signatur».

    Brev med i prinsippet samme innhold skal være like. Hvis en saksbehandler jobber med en sak og innvilger en søknad, og en annen saksbehandler innvilger en annen søknad bør begge innvilgelsesbrevene være like (med unntak for det som faktisk er spesifikt for hver sak). 

  • Noe innhold skal presenteres på flere språkformer, f.eks. på bokmål, nynorsk og engelsk fordi mottakere ønsker det. I så fall skal tekstene vurderes/skrives av noen som er kompetente på de språkformene. 
  • Brev som kan genereres automatisk skal genereres automatisk. Dette sparer tid i saksbehandlingen, gir like brev og gjør at vi raskere kan sende ut brev når noe skjer. F.eks. hvis vi har en automatisk saksbehandlingsprosess er det fint hvis du kan sende vedtaksbrevet med en gang i stedet for å måtte be en menneskelig saksbehandler om å sette seg inn i saken og skrive et brev som formidler resultatet. 

Disse prinsippene kan fravikes når det er gode grunner for det. 

En mulig innvending mot prinsippene ovenfor er at det leder til sentralisering av brev og tekst i organisasjonen. Det kan føre til at det tar lenger tid å opprette nye brev eller endre eksisterende brev. Det er sant at det kan skje, men det er ikke sant at det må skje. Det må også veies opp mot hvor viktige disse prinsippene er for organisasjonen, så du kan ende med ulike grader av sentralisering. Vi skal videre se på metoder og verktøy som kan brukes på ulike måter avhengig av hvor mye vekt du legger på de ulike behovene og ønskene over. 

Fraselager 

En måte å oppnå flere av behovene og ønskene over er å ha et sted der alle tekster til brev lagres. Jeg bruker ordet fraselager, der en frase er en tekst. Det kan være en setning eller et helt avsnitt, men er aldri mindre enn én setning. En frase vil ha en viss formatering, og kan inneholde overskrifter, lister med kulepunkter osv. 

Jeg forutsetter at et brev skrevet på bokmål, nynorsk eller engelsk kan struktureres på samme måte og oversettes avsnitt for avsnitt eller til og med setning for setning. Du må tenke på helheten i teksten, men jeg tror det er mulig å si at en viss setning eller et avsnitt på bokmål kan være ekvivalent til en setning eller et avsnitt på engelsk. Det kan finnes unntak, og de kan håndteres, men dette er hovedregelen. 

Vi kan lage et enkelt fraselager slik:

Her har vi formatert teksten mellom <h2> og </h2> som overskrift nivå 2. Vi kunne også hatt fet, kursiv, ulike skriftstørrelser osv. Der det er rød skrift på entall/flertall som f.eks. du/dere kan styres av f.eks. om du skriver brev til en person eller en organisasjon. Feltene <forsinkelsesrentesats> og <rentebeløp> skal fylles ut med konkrete tall i hvert enkelt brev. Vi kaller slike felt «flettefelt», for å vise at her skal det flettes inn noe i setningene. 

Dersom du har en slik liste over tekster kan du be alle som skal skrive nye tekster om å bruke tekstene hvis de kan. Nye brev kan skrives ved å plukke noen eksisterende tekster og lage noen nye. Du får likere tekster og likere kommunikasjon, og kan spare tid på å formulere egne tekster og ta dem gjennom juridisk godkjenning. Du slipper å oversette samme tekst mellom bokmål, nynorsk og engelsk flere ganger, fordi alle kan bruke samme oversettelse. 

En slik liste kan bli uoversiktlig, så vi kan legge til noen identifikatorer. I tabellen under er det kolonnene «Nivå 1», «Nivå 2» og «Nivå 3»: 

Disse identifikatorene kan brukes til å filtrere og sortere listen, og de kan brukes til å bygge opp en brevmal med ulike fraser. Dette kommer jeg nærmere tilbake til i neste blogginnlegg.   

Vi kan også ønske å ha lovhenvisninger i brevene våre. F.eks. kan det være slik at hver gang vi skriver om forsinkelsesrenter ønsker vi å henvise til en viss paragraf i en viss lov. Det er positivt om ikke alle må finne ut selv hvilken paragraf de skal henvise til, f.eks. om det er «forsinkelsesrenteloven §§ 14 og 15» eller om det er «forsinkelsesrenteloven kap 3». Det er også fint om alle som skal henvise til dette gjør det på samme måte, altså at de bare har én av følgende: «vår rett til å beregne forsinkelsesrenter, se forsinkelsesrenteloven §§ 14 og 15», eller «for info om hvorfor vi beregner forsinkelsesrenter kan du se §§ 14 og 15 i forsinkelsesrenteloven». Hvis du lager dette en gang for alle, får du likt uttrykk, og alle nye brukere av samme tekst slipper å tenke over hvordan det skal se ut. En måte å gjøre det på er å knytte enkelte lovhenvisninger til enkelte fraser. Jeg fjerner nå nynorsk og engelsk for at tabellen ikke skal bli for bred. 

På denne måten vil alle brev som har frasen felles/forsinkelsesrenter/tekst få med seg samme lovhenvisning i brevet. Slike lovhenvisninger kan listes opp i en egen del av brevet under en overskrift som f.eks. «Relevante regler for dette brevet». 

For å lage et nytt brev kan du gjøre følgende: 

  1. Finn ut hva som må være med i brevet for å tilfredsstille lovkrav. 
  2. Tenk over hva annet du vil ha med  
  3. Tenk over omtrent hvordan du vil skrive og strukturere brevet, men ikke for detaljert. 
  4. Se gjennom fraselageret for å finne passende tekster, spesielt under «felles». 
  5. Skriv eventuelt nye tekster du trenger som ikke allerede er i fraselageret. 
  6. Nye tekster skal legges inn i fraselageret. Alt innhold i alle brev skal være der. 

Alt dette kan faktisk brukes til å lage brevmaler som du deler ut til saksbehandlerne for manuell brevskriving, men en viktig fordel kommer når det brukes til å generere brev automatisk. Dette skal vi se nærmere på i neste innlegg på fagbloggen. Her kan du lese del 2.

Øystein Grøndahl

Rådgiver

oystein.grondahl@decisive.no

Grønn koding: Bærekraftig koding for en grønnere fremtid

oktober 17, 2024

Innledning

Ettersom verden blir stadig mer digitalisert, er det relevant og nødvendig å rette søkelys på hvilken påvirkning digitaliseringen kan ha på miljøet. IT-sektoren er en av de raskest voksende industriene globalt, og den står for en stadig økende andel av de globale CO2-utslippene. Faktum er at IT-sektoren gir like store klimaavtrykk som flysektoren [1]. Som følge av denne utviklingen, har grønn IT og mer spesifikt grønn koding blitt et fremvoksende konsept.

I dette blogginnlegget søker jeg å gi et innblikk i hva grønn koding er, hvorfor det er viktig, og hvordan utviklere kan implementere bærekraftig kode.

Hva er grønn koding?

“Green coding is an environmentally sustainable computing practice that seeks to minimize the energy involved in processing lines of code and, in turn, help organizations reduce overall energy consumption.” [2]

Grønn koding er et segment av grønn databehandling (grønn IT). Grønn databehandling er en praksis, dvs. fabrikasjon, bruk og avhending av IT-utstyr, som har som mål å begrense teknologiens klimaavtrykk. Grønn koding dreier seg om å utvikle programvare som påvirker miljøet i så liten grad som mulig. Mer konkret vil det si å skrive kode som er energieffektiv, ressursbesparende og optimalisert for å kjøre på enheter og servere med lavt energiforbruk. Et hovedpoeng med grønn koding er altså at programkoden er effektiv. Med dette menes det at koden ikke gjør mer enn nødvendig for å oppnå sitt definerte funksjonelle formål.

Grønn koding handler også om hele programvarens livssyklus, fra utvikling og distribusjon til bruk og avvikling.

Flere open-source prosjekter og fellesskap har begynt å fokusere på bærekraft i programvareutvikling. Green Software Foundation er et eksempel på et initiativ som samler utviklere, forskere og organisasjoner for å fremme energieffektiv og bærekraftig programvare.

Hvorfor er grønn koding viktig?

Dagens digitale infrastruktur drives i utstrakt grad av datasentre. For å opprettholde drift, kjøling og sikkerhet forbruker datasentre veldig store mengder energi. Stadig økende databehandling skaper store mengder varme, som igjen krever energi for å avkjøles. Her spiller grønn koding en viktig rolle. Grønn koding kan bidra til å redusere energiforbruket i IT-sektoren, og derav redusere sektorens klimaavtrykk. Dette kan oppnås ved å optimalisere programvarens bruk av ressurser. Effektiv kode som grønn koding representerer kan redusere behovet for maskinvareoppgraderinger, forlenge levetiden til eksisterende teknologi, og altså minimere energikostnader. Alt dette uten å gå på bekostning av ytelsen.

Grønn koding vil ikke bare kunne være fordelaktig for miljøet, men også for organisasjonen som implementerer det [3]. Hvis grønn koding gjør at organisasjonen forbruker mindre energi, kan dette gi økonomiske besparelser, som vil bidra til å opprettholde forretningens bærekraft. Dessuten kan en organisasjon som forplikter seg til bærekraft, trolig få et bedre omdømme og derav potensielt øke sin markedsappell blant miljøbevisste kunder [4].

Hvordan implementere grønn kode?

En fundamental forutsetning for at en organisasjon skal kunne redusere sin miljøpåvirkning, er at organisasjonen forstår hvilken miljøpåvirkning den har. På den måten kan organisasjonen legge planer og ta veloverveide beslutninger om hvilke bærekraftige programvareutviklingstiltak de bør gjøre for å maksimere effekten. Det fins en mengde målemetoder som kan brukes for å vurdere og forstå miljøpåvirkningen. Mange programvare- og skyleverandører tilbyr verktøy og dashboards som kan synliggjøre miljøpåvirkningen til tjenester som en organisasjon benytter. Noen eksempler er AWS Carbon Footprint Tool og Azure Emissions Dashboard [3].

Hvis man har gjort tiltak for å introdusere grønn tenkning i en organisasjon, vil det øke sjansen for en kulturendring i organisasjonen med mer fokus på bærekraft i hver ansatt sitt daglige arbeid [3]. Dette vil gjøre det enklere å implementere grønn koding.

Når det gjelder IT-arkitektur, er det anbefalt ut ifra et grønt koding perspektiv å satse på mikrotjenester fremfor monolitt [3]. I en monolittisk applikasjon er alle komponenter og all funksjonalitet pakket sammen. Hvis en komponent i en monolitt opplever høy etterspørsel, må som oftest hele applikasjonen skaleres. Dette kan føre til at ressursene brukes mindre effektivt. Med en mikrotjenestearkitektur er applikasjonen delt opp i flere uavhengige tjenester som kan rulles ut og skaleres hver for seg. Det vil gi bedre ressursbruk, serverutnyttelse og generelt bedre energieffektivitet.

Et annet tiltak for å optimalisere serverbruk er containerisering (f.eks Docker) eller virtualisering [4]. Dette kan maksimere bruken av serverressurser og redusere behovet for flere fysiske servere og dermed energibruken. Hvis de brukes på riktig måte, kan skyplattformer være energibesparende. Ressursskaleringsløsninger som skyleverandører ofte tilbyr, kan optimalisere ressursforbruket i forhold til etterspørselen.

Det finnes noen mer konkrete implementasjonsråd hva angår grønn koding:

  • Optimalisering av algoritmer: Ved å bruke effektive algoritmer som bruker mindre prosessorkraft og minne, kan dette redusere energien som kreves for å kjøre koden. [4]
  • Unngå redundant kode: Ved å fjerne unødvendig og ubrukt kode vil mengden prosessering som trengs bli redusert, noe som igjen reduserer energibruken. Dette vil også forenkle vedlikehold av programvaren. [5]
  • Begrens bruk av løkker: Løkker er ofte veldig ressursintensive, ettersom de kan utføre et stort antall beregninger. Ved å minimere antallet løkker, kan man optimalisere dataprosesseringen. [7]
  • Asynkron programmering: Å kjøre prosesser i parallell (asynkront) kan øke effektiviteten og redusere energibruken. Synkronitet gir mer ventetid for prosessoren og dermed mer unødvendig energibruk. [6]
  • Caching-teknikker: Implementasjon av caching av eksempelvis ofte aksesserte data i minnet, kan gi besparelser i prosesseringstid. [7]
  • Lazy loading: Ved å bare laste data når det trengs, kan utviklere redusere minne-fotavtrykket i programvaren. [7]
  • Oppdater til nyere versjoner: Ressursbruk kan optimaliseres ved å ta i bruk oppdaterte biblioteker og rammeverk
  • Valg av programmeringsspråk: Programmeringsspråk har ulik energieffektivitet. C, C++ og Rust er kjent for å være noen av de mest energieffektive språkene. Python og Ruby er ansett for å være blant de minst energieffektive. [4]
  • Open source software: Åpen kildekode-programvare kan bidra til bærekraft ved redusert behov for utvikling fra bunnen av, noe som sparer tid og ressurser. [4]

 

Avslutning

Grønn koding er et sentralt konsept innen grønn databehandling. Det er en mulighet til å kombinere teknologi med ansvar. Ved å gjøre små justeringer i hvordan vi skriver og optimaliserer kode, kan utviklere bidra til å redusere teknologiens miljøpåvirkning og fremme en grønnere fremtid.


Kilder

[1] https://www.tu.no/artikler/it-bransjen-har-like-stort-klimaavtrykk-som-flybransjen-hva-gjor-vi-med-det/486098
[2] https://www.ibm.com/think/topics/green-coding
[3] https://www.computer.org/publications/tech-news/trends/implementing-green-coding-practices
[4] https://green.org/2024/05/24/best-practices-of-sustainable-software-development/
[5] https://greensoftware.foundation/articles/10-recommendations-for-green-software-development
[6] https://www.asioso.com/en_BA/blog/green-code-4-principles-for-environmentally-friendly-software-development-b1001
[7] https://www.suso.academy/en/2023/03/13/green-coding-the-5-most-important-basics-for-sustainable-software-development-with-code-examples/

 

Espen Vikskjold

Sjefskonsulent

espen.vikskjold@decisive.no

Erfaringer med SMARTS fra en forretningsarkitekt

september 19, 2024

På denne bloggen har det allerede blitt skrevet en del innlegg som handler om Decision Intelligence Platform (DIP), eller beslutningsstyringssystem på norsk. Jeg ønsker å skrive litt om min opplevelse med SMARTS fra en person som har bakgrunn som forretningsarkitekt, der hovedfokuset oftest er på krav, forretningsprosesser og livlige diskusjoner mellom personer i grenselandet mellom IT og fag. 

Alf-Kenneth har allerede skrevet en god introduksjon til hva SMARTS er, og fordeler ved å bruke verktøyet. Øystein har skrevet et 2-delt innlegg om hvordan A-B testing i SMARTS kan utføres, der det er synliggjort hvordan du enkelt kan vurdere konsekvenser av endringer i reglene.  

Uten den tekniske bakgrunnen kan det oppleves som å vandre inn i ukjent terreng med mange fallgruver når man selv skal begynne å «kode» regler. Mitt hovedpoeng er at det er det liten grunn til, fordi dette er så enkelt at man kan lære seg de mest elementære (og viktigste) bruksområdene på kort tid – uten særlig teknisk kompetanse. Jeg har nå brukt en knapp uke på å sette meg inn i SMARTS, og selv om jeg ikke kan påberope meg ekspertise på systemet kan jeg allerede nok til å sette opp et enkelt regelsett med fakta, vilkår og utfall. Og vel så viktig kanskje – jeg kan lese og forstå hva som foregår i etablerte regelsett uten å måtte ty til utviklere for hjelp. Om du  har satt opp et Excel-ark med noen enkle formler er du kapabel til å ta i bruk SMARTS, som er et såkalt «Low-code/No-Code» verktøy. 

Uten at jeg kan eller skal skrive en komplett guide her, vil jeg vise hvor enkelt det er å sette opp et enkelt regelsett med noen fakta og en enkel beslutningstabell. Med min bakgrunn fra pensjonsfaget er jeg moralsk forpliktet til å ta et eksempel derfra. Vilkårene for innvilgelse av «påslagspensjon» (fra offentlig sektor) er gjort betraktelig enklere sammenlignet med den gamle «brutto-ordningen», og handler i hovedtrekk om tre enkle vilkår: 

  • Medlemmet må være fylt 62 år  
  • Medlemmet må ha søkt i tide (med andre ord kan en ikke søke tilbake i tid)
  • Medlemmet må ha minimum 1 dag opptjening etter 31.12.2019  

(Så håper jeg at mine kollegaer med pensjonskompetanse kan tilgi meg for å ha gjort noen forenklinger for eksempelets skyld) 

Rekkefølgen for hvordan man ønsker å gjøre dette er fleksibel, men vi ser med en gang at vi her trenger å få etablert tre enkle faktum. Vi begynner med å sette opp faktum i SMARTS, som tre true/false (boolske) variabler.  

I SMARTS har du i prinsippet mulighet til å strukturere felter og seksjoner som du ønsker, men for å gjøre et tydelig skille mellom hva som er input (som er avhengig av- og prisgitt eksterne data og deres modeller) og fakta anbefaler vi at regler kjører på det vi enkelt kaller «fakta». Hva som er fakta i denne sammenhengen er det lovverket som bestemmer – ikke hva man har som input i en gitt kontekst. Rent praktisk er det å legge til seksjoner og felter svært enkelt – så lenge man tar stilling til datatypen (som i dette tilfellet altså er boolske).  

I SMARTS kan vi med enkle grep benytte oss av disse faktaene og sette opp regelen som en beslutningstabell:  

Tabellen viser de tre vilkårene (sendt innen fristen, fylt 62 år og har opptjening etter 31.12.2019) som kolonneoverskrifter. Hver rad i tabellen kan ses på som en regel – der utfallet av hver regel leses i den siste kolonnen (VilkårForPåslagOppfylt).

Noe forenklet forklart er dette så enkelt som å trykke add new decision table, og legge til rader og kolonner (add row og add column). Den mest kompliserte biten er å knytte kolonnene med de (etablerte) fakta til tabellen – og det tok ca. 2 minutter. Ellers er det å fylle inn enten «true» eller «false» slik at en får en fullstendig tabell med alle potensielle varianter.   

Utfallet fastsetter her verdien «Vilkår for påslag oppfylt» som enten true eller false. Her har du mulighet til å legge inn flere utfalls-kolonner, om du for eksempel vil legge til hjemmelshenvisning, begrunnelse eller annet for hver rad som kan slå til.   

Når jeg har fylt inn tabellen kan jeg endre visning av regelen til rule list, der jeg ser koden som er generert:  

Bildet viser de samme reglene som uttrykt i beslutningstabellen over som individuelle kodede regler. I hver regel er det en tittel (fet skrift), vilkår og utfall.

Foreløpig har vi tatt utgangspunkt i en regel der forutsetningen er at faktum er etablert. I den virkelige verden vil vi også måtte utlede disse faktaene – med andre ord transformere input til de faktaene vi trenger. Her er det flere veier til mål, men én enkel mulighet er å utlede dette med flere regler i SMARTS. I mitt eksempel har jeg skilt mellom regler som utleder fakta, og vilkårsregler (som igjen kjører på fakta). For å utlede fakta har jeg lagt inn noen enkle utledningsregler: 

Utledningsreglene fastsetter altså de fakta som vi benytter for å kjøre de «reelle» forretningsreglene våre. Dette var nok det vanskeligste å få fatt på for min del – men her er det prøving og feiling, og det å gjøre seg kjent med SMARTS sin dokumentasjon og veiledning som gjelder. Du kan også få hjelp av den innebygde AI-assistenten til SMARTS, som jeg har vist med et enkelt eksempel her:  

Det er langt flere muligheter og funksjoner i SMARTS enn det jeg har fått vist med mitt enkle eksempel her – og erfarne brukere eller kodere vil nok ikke være 100% overbevist av mitt forsøk på å implementere denne regelen. Men det er heller ikke poenget med denne bloggposten.  

Som funksjonell arkitekt er det en kjent problemstilling at forretningslogikken er lite tilgjengelig. Både fagpersoner, forretningsressurser, testere og andre har ofte lite innsikt og tilgang til den faktiske koden. Og selv om vi hadde sittet med koden foran oss er det ikke gitt at vi hadde blitt mye klokere. Fagpersoner som sitter med den faktiske forretningskompetansen jobber aktivt med faget og utarbeider oppslagsverk og wikier, men har sjelden eierskapet eller innsikten i den faktiske implementeringen – som i realiteten er måten de samme reglene praktiseres på.  

Når systembrukere oppdager feil eller mangler i eksisterende systemer er det ofte en tungrodd prosess å spore hva som faktisk foregår. Feilsøking og påfølgende kravspesifisering og retting kan være tidkrevende og frustrerende. Ofte er systemer eller tjenester såkalte «black boxes» – der få (eller ingen) i virksomheten helt vet hvordan løsningen fungerer. Men hva om saksbehandleren eller fageksperten selv kunne gå rett inn å sjekke den faktiske regelimplementeringen? Eller enda bedre – om fageksperten selv kunne rettet feilen med noen tastetrykk?  

Å spore hvilke regler som er kjørt – og eventuelt slått til er heller ikke særlig problematisk i SMARTS. I eksempelet nedenfor kan jeg se (med «grønt lys») hvilke regler som har slått til i mitt testcase: 

 

Én av hensiktene med DIP er altså å la fagekspertene selv få innsikt og til syvende og sist eierskap til de praktiserte reglene i systemene. Det er et oppnåelig mål, og spesielt for virksomheter der kompliserte forretningsregler er en del av hverdagen. Betyr det at det også er et mål å «kvitte seg» med utviklere eller systemarkitekter? Selvsagt ikke. For å ta i bruk en DIP kreves det integrasjoner, kvalitetssikring og testing for å nevne noe. For komplekse regler vil også det å utlede fakta være krevende – og i større grad kreve kompetanse med koding. Vi ønsker heller ikke at fageksperter skal bli fulltidskodere (med mindre de selv har veldig lyst) – men jeg har forsøkt å vise (med de rette hjelpemidlene) at gapet mellom forretning og IT kan bli litt mindre med enkle grep.  

Vebjørn Roald

Rådgiver

vebjorn.roald@decisive.no

Parprogrammering – Kan To Hoder Skrive Bedre Kode(r)?  

august 21, 2024

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 

Asgeir Aanonsen

Utvikler

asgeir.aanonsen@decisive.no

Hvordan henger rettsregler og forretningsregler sammen?

juni 13, 2024

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.

Tobias Vigmostad

Rådgiver og teamleder

tobias.vigmostad@decisive.no

Fordeler ved å bruke en Decision Intelligence Platform (DIP) ved implementering av beslutnings-/regeltjenester i en virksomhet

mai 16, 2024

Innledning 

SMARTS er et beslutningsstyringssystem (Decision Intelligence Platform, DIP) 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: 

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.

Alf-Kenneth Aabel

CTO

alf-kenneth.aabel@decisive.no

Infrastructure as Code

april 18, 2024

Hva er Infrastructure as Code?

Enkelt forklart er det å sette opp infrastruktur i skyen automatisk via kode, i motsetning til å sette opp manuelt. En måte å se det på er som regelbasert infrastruktur.

Hva menes med Infrastructure?

Når vi snakker om Infrastructure mener vi byggesteiner i skyen som webservere, databaseservere, lastbalanserere, nettverk, brannmur, virtuelle maskiner og så videre. Og ikke minst hvordan disse er koblet sammen.

Hva menes med Code?

Code er tekst som kan leses av både datamaskiner og mennesker. Denne teksten definerer de forskjellige delene i infrastrukturen. Teksten er ofte deklarativ, det vil si at koden beskriver hvordan infrastrukturen skal se ut, i motsetning til imperativ kode som beskriver hvordan infrastrukturen skal lages, steg for steg.

Koden er gjerne med i kodebasen sammen med resten av systemet, som gjør at alle endringer kan spores.

Hvorfor Infrastructure as Code?

Se for deg et utviklingsmiljø uten Infrastructure as Code, hvor utviklere setter opp infrastruktur manuelt. Over tid vil det bygge seg opp endringer i infrastrukturen, og det blir vanskelig å holde styr på hvordan den faktisk fungerer i forhold til hvordan den er dokumentert. Hvis den er dokumentert i det hele tatt.

Med Infrastructure as Code kan man si at selve definisjonen av infrastrukturen er dokumentasjonen, og det vil da ikke være mulig at det er forskjell på dokumentasjonen og virkeligheten, gitt at IaC-systemet fungerer som det skal.

I tillegg vil enkel tilbakerulling av endringer redusere frykt for å gjøre feil, og øke utviklingshastigheten.
Kode kan gjennomgås av automatiske systemer for å sikre at retningslinjer blir fulgt, for eksempel at databaseservere ikke skal være åpne for hele internett.

En annen fordel med Infrastructure as Code er reproduserbarhet. Et eksempel på det er hvis det blir et behov for et nytt environment, for eksempel for testing. Da kan man lett opprette et environment som er likt produksjons-environment, og da ha visshet om at testingen er treffende for potensielle feil i produksjon.

Forskjellige Infrastructure as Code systemer

Det er massevis av forskjellige IaC-systemer, med hver sin syntaks og fremgangsmåte.
Noen er proprietære og låst fast til en sky, mens andre kan brukes på flere skyer samtidig.

Som eksempel på multicloud har vi Terraform og Ansible. Disse kan brukes på både AWS, Azure og Google Cloud Platform.

Microsoft har sitt eget system kalt Azure Resource Manager, med ARM Templates og Bicep som definisjonsformat. Denne fungerer bare på Azure.

I eksempelet nedenfor ser vi Bicep-kode som beskriver en website:

Her har vi et tilsvarende eksempel på Terraform-kode:

Ulemper

Selv om Infrastructure as Code har mange fordeler, har det også noen ulemper. En ulempe med Infrastructure as Code er at man må lære seg nye systemer, ofte med egne filformater. Utfra hvor mye man definerer må man kanskje inn med noen skript, og dette kan føre til at det fort blir mye forskjellig å tenke på i deployment-pipelinen. For eksempel kan en middels kompleks pipeline involvere språkene Bicep, YAML, JSON, Dockerfile, Powershell og Bash, ofte nøstet inn i hverandre.

Det kan også være en utfordring med økt kobling mellom infrastrukturen og resten av systemet. Man vil gjerne at system skal kunne kjøre på forskjellige environments, og ikke være sensitivt for mindre endringer. Hvis man har IaC deploy og kode deploy i samme CI/CD pipeline som alltid kjører sammen, er det ikke noe der som stopper potensielt uheldige koblinger mellom environment og system.

Infrastructure as Code er også mer sensitivt for feilkonfigurasjon – en liten feil i en IaC template kan forårsake store feil i hele systemet. Dette retter seg spesielt mot feil som ikke umiddelbart blir fanget opp i testing – for eksempel sikkerhetshull hvor nettverk som er åpnet mer enn nødvendig, eller sammenblanding av utviklings- og produksjons-environment.

Å blande manuell prosess med Infrastructure as Code er ikke en god ide – man vil kanskje gjøre en rask endring på en server uten å involvere hele deployment-prosessen. Dette vil kanskje se ut til å fungere greit, helt til det blir gjort en ny deployment, og den manuelle endringen vil bli overskrevet.

Konklusjon

Med kontinuerlig utvikling av muligheter i skyen og stadig nye krav til løsninger er det viktig å ha oversikt over infrastrukturen, og enkelt kunne endre denne. Infrastructure as Code er et effektivt hjelpemiddel for dette, hvor automatisering, reproduserbarhet og dokumentering er noen av de viktigste nytteeffektene.

Hvor uheldig er egentlig en kobling?

mars 14, 2024

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. 

André Rakvåg

Løsningsarkitekt

andre.rakvag@decisive.no