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.

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.  

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.