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).

Turnus-teamet er et lite team på tre personer som jobber med utvikling, forvaltning, test, kvalitetssikring og support av et egenutviklet turnussystem – og alle jobber fra hjemmekontor spredt i landet! Under pandemien ble alle sendt på hjemmekontor, men vi ble værende når samfunnet gikk tilbake til normalen. Vi så at hjemmekontor-løsningen fungerte veldig godt for oss og det er noen nøkkelfaktorer som bidrar til at løsningen fungerer.

Her er våre viktigste erfaringer (og tips!) til å få et velfungerende team basert på hjemmekontor:

1. Arbeidsgiver tilrettelegger for hjemmekontor: Det er ingen forventning fra arbeidsgiver sin side om at teamet skal møte opp på kontoret i det daglige. I tillegg er det opp til hver enkelt om vi vil sitte hjemme å jobbe eller på kontoret.
2. Alle i teamet sitter på hjemmekontor: Når alle sitter på hver sin kant får alle samme tilhørighet til teamet, som ikke hadde vært en selvfølge om noen hadde sittet sammen på kontoret og noen hadde sittet på hjemmekontor. Det er enkelt å ta kontakt med hverandre uten å være redd for å forstyrre andre fordi de som er på jobb sitter i kontorlandskap. I tillegg gjør digitale løsninger som Teams det sømløst å ringe hverandre for en prat eller for å dele skjerm.
3. Lite og selvstendig team med tydelige verdier: Teamet vårt er ikke avhengig av andre utenfor teamet. Vi tar selvstendige avgjørelser, samtidig som vi har enkel tilgang til andre ressurser i selskapet. For oss er en viktig faktor for at teamet fungerer at vi ønsker å nå de samme målene, det er rom for selvstendig initiativ og vi heier alle på hverandre. Det er ingen skjulte agendaer og alle vil hverandre vel.
4. Arbeidsoppgaver som krever individuelt fokus: Komplekse problemstillinger krever rom for konsentrasjon, som er enklere å oppnå på hjemmekontor enn i et åpent kontorlandskap.
5. Faste møtepunkter: Hver morgen møtes vi digitalt kl. 09:00 for å gå igjennom dagens oppgaver og avklarer eventuelle problemstillinger. Vi har også et uformelt ikke-faglig møte der vi snakker om løst og fast og har «kaffemaskin-praten». I løpet av året møtes vi for sosialt og faglig samvær, i tillegg til faste sosiale sammenkomster med hele arbeidsplassen.

Med utsikt som dette er det ikke rart vi trives på hjemmekontor 😊

Forutsetninger som må være på plass for at dette skal fungere

For at vi skal ha samhørighet til hverandre og ikke føle på ensomhet, må vi ha lav terskel for å ha hyppig kontakt. Alle i teamet har dessuten vært i arbeidslivet i mange år og for oss er lang erfaring en viktig faktor for at det skal fungere. Decisive er åpne for at vi kan sitte både hjemme og på kontoret, og når vi enkelt kan velge å jobbe hjemmefra slipper vi å bruke tid og energi på å pendle til og fra kontoret. Decisive holder til på Helsfyr i Oslo, så for et team som bor i Oslo, Østfold og på Vestlandet blir dette viktig for vår trivsel!

Kortversjonen: Ja, business rules eller forretningsregler, er relevant for offentlig forvaltning. Business er ikke en henvisning til noe kommersielt, din business er det du gjør.

Som konsulent og jurist som jobber med automatisering av beslutninger i offentlig forvaltning, hender det (mer før enn nå) at jeg møter på synspunktet om at business rules, eller forretningsregler som det heter på norsk, bare er relevant for kommersielle virksomheter. Kanskje ikke så rart. I Norge er vi vant til å tenke på business som noe kommersielt, men ordet har også en annen betydning – både på norsk og engelsk.

Business refererer til det du gjør, og ikke til noe kommersielt som vi kanskje lett kan tro.

Hvis du graver et lite hull i din egen hage, er det din business, og ikke naboens – som kanskje lurer på hva du gjør. Dersom virksomheten din er å forvalte en pensjonskasse, utbetale integreringstilskudd, utstede førerkort, fatte vedtak om byggetillatelser eller innvilge oppholdstillatelser når vilkårene er oppfylt, er det det som er forretningen din.

At vi på norsk oversatte business rules til forretningsregler lurer jeg på om egentlig var et arbeidsuhell. På svensk kan vi snakke om att få ordning på sina affärer, og de har også affärsregler. Kanskje burde vi omdøpe forretningsregler til foretaksregler eller virksomhetsregler?

 Illustrasjon som viser en metode for å beskrive forretningsregler.

Uansett, hovedpoenget i dette innlegget er at forretningsregler er regler som regulerer det forretningen gjør – selv om forretningen ikke er en kommersiell virksomhet. At forretningsregler har grensesnitt mot både rettsregler og systemregler får jeg komme tilbake til i et annet innlegg.

Selv bruker jeg forretningsregler både til å beskrive akseptansekriterier i brukerhistorier og til å beskrive rettsregler som styrer prosesser og automatiserte beslutninger – også i offentlig forvaltning.

Hvis du er nysgjerrig på hvordan du kan bruke konseptet forretningsregler i din virksomhet til å skrive presise krav som også er enkle å implementere, kan du gjerne ta kontakt.

Decisive starter med dette innlegget vår fagblogg. Bloggen er en måte for oss i Decisive å få formidlet hva vi driver med til daglig og hva vi brenner for. Vi er mange personer som har ulike ting vi synes er spennende, og som vi dermed dykker ned i. 

Det er jo slik med mennesker at ting som interesserer oss vil vi gjerne lære mer om. Og da blir man ofte god på de samme tingene. 

Decisive er satt sammen av tre team. Vi har turnusavdelingen, som forvalter turnussystemet TTA og som hjelper våre TTA-kunder med stort og smått. Vi har systemutvikleravdelingen som består av fullstack Javautviklere IT-arkitekter. I tillegg har vi rådgivningsavdelingen med fokus på å levere gode råd og hjelp til våre kunder på alt fra pensjonskompetanse, personvern og informasjonssikkerhet til innføring og endringsledelse. Rådgivningsavdelingens center of excellence er regelverksutvikling og modellering av regelverk ved bruk av verktøyene i Decisivemetoden, noe jeg er helt sikker på at vil komme til syne på denne bloggen. 

På denne bloggen vil det derfor komme innlegg fra alle typer kompetanser vi er satt sammen av. Være seg IT-arkitektur, programmering, integrasjoner, turnusutfordringer, prosessledelse, innføring, regelverksutvikling eller bruk av Decision Management Systems, både off-the-shelf og selvlaget. 

Jeg gleder meg «sykt» til å lese de forskjellige innleggene, for i Decisive har vi mange forskjellige kompetente mennesker som har noe å formidle!