AI er et system hvor en eller flere maskinlæringsmodeller produserer datadrevne prediksjoner. Systemet benytter prediksjonene til å velge datadrevne handlinger basert på tidligere digitale registreringer eller transaksjoner.
Hver dag bruker millioner av mennesker løsninger som er laget av Knowit Solutions. Vi som jobber her er sultne på å lære og liker å dele kompetansen vår – både med kolleger og omverdenen.
AI er et system hvor en eller flere maskinlæringsmodeller produserer datadrevne prediksjoner. Systemet benytter prediksjonene til å velge datadrevne handlinger basert på tidligere digitale registreringer eller transaksjoner.
I forrige artikkel lovet jeg dere mer om metoder, verktøy og eksempler. I denne artikkelen viser jeg hvordan noen verktøy eller øvelser fra forretningsdesign kan brukes enkeltvis eller satt i system. La meg hoppe rett ut i det.
Å lage tverrsektorielle, proaktive og individuelle innbyggertjenester har vært offentlig sektors våte drøm helt siden man begynte å tenke seriøst på digitalisering sånn rundt årtusenskiftet. Men hvor blir det av disse tjenestene? Og behøver det egentlig å være så innmari vanskelig?
En god kollega sa en gang noe sånt som at "det finnes ikke noe som er kjedeligere enn å se på at en kunde modner". Og det har han jo helt rett i – maling som tørker er jo rene sprintøvelsen sammenliknet med modningsreiser, som jo mange ganger kan være ganske langtrukne og slitsomme øvelser for alle involverte. Likevel er det å bidra til modning hos kunden noe av det viktigste vi gjør som konsulenter.
Da er det 1. desember og vi har allerede tent det første adventslyset. Det har vært en travel høst for de fleste med mye på agendaen, samt mange konferanser og arrangementer. Hvis du er nysgjerrig på hva folk i Knowit har drevet med i det siste, så kan du ta en titt på videoene her 😍
Maintaining architecture governance in a world of agile development can seem difficult. Christian Holmboe writes about what we can learn from the management of the COVID-19 pandemic.
Det finnes ikke en konsensus i IT-bransjen rundt metrikker som hjelper oss å måle produktivitet og som setter utvikler-team i stand til å forbedre seg selv. Vi har gått gjennom forskning og funnet et tydelig budskap som forklarer hvorfor metrikker er så vanskelig: Metrikker bør brukes til å sette team i stand til å forbedre seg selv – ikke til å kontrollere og belønne dem.
Har du noen gang lurt på hvorfor visse uforskyldte problemer ender opp hos deg, eller hvordan du unngår at det skjer?
De fleste som har vært i arbeidslivet (eller politikken), har hørt om «skjeletter» som har tendens til å «ramle ut av skap». I dette innlegget skriver jeg om hva «skjeletter» er, hvorfor de oppstår og hva som skal til for å unngå at de blir ditt endelikt.
Skrevet av Anne-Line Dahlen og Jørn Atle Husbyn. DataOps (Data Operations) er et relativt nytt begrep som har dukket opp i løpet av de siste årene og henter inspirasjon fra blant annet DevOps, Agile og Lean. Dette er en tankegang som skal gjøre datahåndtering i selskaper lettere, for å få verdi ut av store informasjonsmengder. Siden begrepet DataOps er såpass nytt finnes det heller ikke noen felles akseptert definisjon, men i denne bloggposten skal vi prøve å forklare hva DataOps er og dele våre tanker rundt temaet.
Når noen vi kjenner spør oss om vi kan gjøre de en tjeneste vil de fleste av oss gjerne stille opp. Om det er en nær relasjon som spør trenger du kanskje ikke engang å høre hva du skal bidra med før du sier ja. Det handler om tillit. Du stoler på den som spør deg, og du hjelper gjerne. Du er samtidig trygg på at den som spør vil stille opp for deg når du har behov for bistand. Å gjøre noen en tjeneste handler om å investere tid og ressurser i en relasjon.
Finnes det noen likheter mellom det å gjøre noen en tjeneste privat og tjenestebaserte forretningsmodeller? De viktigste fellestrekkene ligger i relasjonen som nøkkel til gjensidig verdiskapning.
Vi skal i dette innlegget se på hva som gjør tjenestebaserte forretningsmodeller attraktive og hva som er viktig å tenke på både når man utvikler og anskaffer tjenester.
Hjelper du meg, skal jeg hjelpe deg – sammen er vi sterke!
Når vi gjør noen en tjeneste uten å ta betalt gjør vi det for å hjelpe. Har vi en sterk relasjon gjør vi det uforbeholdent uten å be om å få noe tilbake. Vi gjør kanskje tjenesten for å styrke eller bevare relasjonen. Om det ikke ligger en sterk relasjon til grunn forventer vi kanskje å kunne be om en tjeneste tilbake ved en senere anledning.
Vi kan si at det som oftest ligger en forventning om en felles verdiskapning. Det er sjelden helt gratis når noen gjør deg en tjeneste. Eller som ordtaket sier: “There is no such thing as a free lunch!”. Likevel vil det å hjelpe hverandre bidra til å styrke relasjoner og gjøre livet enklere. I balanserte relasjoner er det å gjøre hverandre tjenester med på å skape verdi for alle parter.
Hva er sammenhengen mellom tjeneste og produkt?
Med produkt mener vi som oftest noe som er laget for å bli solgt, vanligvis noe som er produsert gjennom en industriell prosess. Produkter kan være matvarer, forbrukerelektronikk, klær osv. Produkter behøver ikke være fysiske gjenstander. Vi kan si at produkter er konfigurasjon av en organisasjons ressurser satt sammen for å kunne dekke et markedsbehov. Eksempler på ressurser kan være: ansatte, prosesser, leverandører, IT-systemer osv.
Ordet tjeneste betyr i sin enkleste form at en hjelper eller utfører arbeid for noen. Med tjeneste mener vi en transaksjon der fysiske gjenstander ikke bytter eier. Dette skiller seg fra transaksjoner der en vare bytter eier. Når vi leverer en tjeneste kan vi si det er en måte å tilgjengeliggjøre verdiskapning sammen med kunder gjennom å tilrettelegge for de effekter kunden ønsker å oppnå. Dette gjøres uten at kunden selv må ta eierskap til kostnader og risiko som ligger i å produsere tjenesten.
Tjenester kan for eksempel være telefonabonnement, undervisningstimer eller tilgang til strømmetjenester. Vi kan også ha tjenester der fysiske gjenstander er involvert, men hvor eierskapet til gjenstanden ikke overføres til kunden. For eksempel mobiltelefon som tjeneste eller bil som tjeneste. Dette er forretningsmodeller hvor kunden betaler for tilgang til et produkt med tilhørende egenskaper inkludert. For eksempel reparasjoner, support eller oppgraderinger.
Hvorfor er tjenesterelasjonen så viktig?
Vi kan ikke si at vi har en tjeneste uten at det er etablert en tjenesterelasjon. Vi kan ha produkter som er designet for å skape verdi for en forbruker. Når disse produktene tilbys en kunde med pris og tilhørende egenskaper sier vi at vi har et tjenestetilbud. Et tjenestetilbud kan omfatte produkter, tilgang til ressurser og tjenestehandlinger der kunden får bruksrett, men ikke eierskap.
Selve tjenesten eksisterer først når vi har etablert en tjenesterelasjon. Når vi oppretter en tjenesterelasjon gjør vi det gjerne ved at det inngås en avtale mellom kunde og leverandør. Når tjenesten leveres etablerer vi en instans av tjenesten for den spesifikke kunden.
Når en kunde starter å ta i bruk en tjeneste og denne tjenesten skaper verdi er tjenesten etablert. På leverandørsiden av tjenesterelasjonen skjer det tjenesteproduksjon og på kundesiden av tjenesterelasjonen skjer det tjenesteforbruk. Mellom kunde og leverandør administreres tjenesteforholdet og relasjonen pleies.
Figuren under viser forholdet mellom ressurser, produkter, tjenestetilbud, og tjeneste.
Kjeder av tjenesterelasjoner
Alle selskap er ledd i en verdikjede og de fleste både kjøper og selger tjenester. Man kan eksempelvis kjøpe regnskapstjenester, IT tjenester, logistikktjenester eller juridiske tjenester. Selv innenfor en bedrift kan det være kjeder av tjenesteproduksjon og tilhørende konsumering av tjenester. Eksempelvis kan en lønnsavdeling yte lønnstjenester for alle i et selskap eller alle selskap og datterselskap i en konsernstruktur.
Eksempel på kjeder av tjenesterelasjoner kan være følgende: Et selskap som selger regnskapstjenester selger sine tjenester til et IT-selskap, som selger sine tjenester til et advokatfirma, som selger sine tjenester til et logistikkselskap, som selger sine tjenester til en kaffeleverandør, som selger sine tjenester til et regnskapsfirma osv.
Figuren under viser kjeder av tjenesterelasjoner mellom virksomheter.
Gjensidig verdiskaping gjennom tjenesterelasjon
På samme måte som når vi gjør en tjeneste for noen privat er det viktig med gode relasjoner i salg og kjøp av tjenester. Verdiskapning må skje både på kunde og leverandørsiden. Om tjenestekjøpet ikke skaper tilstrekkelig verdi hos en kunde vil behovet for tjenestekjøp bortfalle, og kunden avslutter tjenesterelasjonen. Et selskap som ikke tjener eller skaper verdi på tjenestene de leverer vil som oftest avvikle disse eller i verste fall avvikle selskapet. På den andre siden vil et selskap som har stor verdi av tjenestene de kjøper kunne utvikle sin forretning og kjøpe flere tjenester. Økt etterspørsel eller økt verdiskapning vil også gjøre at en tjenesteleverandør vil kunne utvikle sin virksomhet og selge mer tjenester, samt ta seg bedre betalt for disse. I tillegg vil virksomheten skape handlingsrom for å utvikle nye tjenester. Gjensidig verdiskapning er sentralt i kjøp, salg og utvikling av gode tjenester. Økt verdiskapning på begge sider av tjenesterelasjonen gir grunnlag for vekst og utvikling hos begge parter.
Sentralt i tjenesterelasjonen ligger at denne kontinuerlig utvikles gjennom god dialog. Dialogen kan skje på mange måter. For tjenesteleverandøren er det viktig å følge med på markedet og få innspill fra kundene til hvordan tjenestene bør utvikles for å støtte nåværende og fremtidige behov. For kunden er det viktig å ha tilsvarende dialog for påvirke tjenesteutvikling til å dekke deres behov best mulig. Slik kan de tilrettelegge for best mulig resultat i sitt selskap.
Hvilke tjenester bør vi kjøpe og hvilke skal vi produsere selv?
Når et selskap skal konkurrere i dagens tøffe markeder må det tas gode valg i forhold til hvilke funksjoner virksomheten skal produsere selv og hvilke funksjoner det er mer hensiktsmessig å anskaffe. Vi kjøper tjenester fordi det er billigere, innebærer mindre risiko eller rett og slett fordi det hindrer at vi tar fokus bort fra det vi ønsker å bli gode på. Vi produserer tjenester selv når det er en del av vår kjernevirksomhet, kjernekompetanse eller funksjoner som understøtter disse. Vi må velge hva vi skal bli gode på fordi det er vanskelig å bli god i alt.
Om vi for eksempel er gode på å designe og produsere bilmotorer er det ikke sikkert vi ønsker å bruke tid og penger på å bygge opp en egen lønns- eller regnskapsfunksjon. Det er heller ikke sikkert at vi ønsker å bruke innsatsen på å bygge kunnskap og kapasitet om logistikk og leveranser. Dette vil være tjenester det er naturlig å kjøpe av noen som har riktig kompetanse og kapasitet for å dekke våre behov.
Hvordan skal ulike tjenester skape verdi?
Som tidligere nevnt er det viktig at tjenester skaper verdi for å ha eksistensgrunnlag. Når vi leverer en tjeneste forventer vi ofte at det skal gi oss verdi i form av økonomisk utbytte. Samtidig bør tjenester vi skaper være med på å utvikle kompetanse og kapasitet som er sentrale i egen virksomhet. Det kan i tillegg være et mål at tjenesten skaper trivsel og motivasjon hos medarbeidere. I noen tilfeller kan det også være at tjenestene bidrar til andre former for verdiskapning. For eksempel verdier som er nyttig for samfunnet, miljøet eller liknende.
Å utvikle tjenester for salg har likhetstrekk med å gjøre noen en tjeneste privat
Mål med å tilby tjenester er å dekke markedsbehov som kunder ikke kan eller ønsker å produsere selv. For å få til dette må vi designe gode tjenester som skaper verdi for både kunde og leverandør. Verdiskapingen bør utvikles over tid slik at tjenesten stadig skaper økt verdi og til enhver tid er konkurransedyktig. Verdiskapningen skjer gjennom utvikling av relasjonen mellom partene.
På samme måte er det med private relasjoner. Relasjonene må pleies over tid og vi må stadig tilføre hverandre opplevd verdi. Ikke bare gjennom tjenester vi gjør for hverandre, men gjennom alle handlinger som påvirker relasjonen. Tenk at du investerer i en forretningsrelasjon på samme måte som i en privat relasjon. Om begge parter ønsker hverandre vel og jobber for at forholdet skal vokse vil det tjene begge parter og sjansen for felles måloppnåelse er stor.
Ta tak i virksomheten! - Gå i gang med å skape enda bedre tjenester
Når du som leverandør skal levere og videreutvikle tjenester bør du fokusere på verdiskapning. Start der du er i dag og ikke gjør ting for komplisert. Utvikle tjenestene dine gjennom tilbakemelding fra kundene. Jobb med å holde verdikjedene enkle og praktiske og optimaliser og automatiser i alle ledd.
Når du som kunde har bestemt deg for å kjøpe en tjeneste bør du fokusere på å få ut maksimal verdi. Velg tjenester som dekker dine behov. Bruk en leverandør du stoler på som du er trygg på at vil strekke seg for at du som kunde skal nå dine mål. Velg en leverandør med gode referanser og sikre at du har gode avtaler med tydelige leveransebeskrivelser og balanserte ansvarsforhold.
I Knowit leverer vi konsulenttjenester etter as-a-service modellen der kundene betaler abonnementspris. Vi setter sammen kompetanse, metode og verktøy for å skape høyest mulig verdi gjennom tjenestene vi leverer. Dette gjør vi i tett partnerskap med våre kunder for å sikre at vi bidrar til målbare konkurransefortrinn. Når kunder eksempelvis skal endre sin virksomhet til å utnytte potensiale som ligger i digitale forretningsmodeller bistår vi gjennom hele reisen.
Om du ønsker å mer informasjon om tjenestebaserte forretningsmodeller kan du lese mer om det i vårt tidligere blogg-innlegg "Hva kan konsulentbransjen lære av Netflix?"
Knowit har lang erfaring og kompetanse på skybaserte løsninger, og gjennom pandemien har vi valgt å øke vår satsning på skytjenester og cloud-sertifiseringer. Som konsulent er det viktig å imøtekomme de behovene som finnes på markedet, spesielt når det kommer til teknologi som utvikler seg i hurtig tempo. I dette innlegget har vi hentet frem noen av våre ansatte som sitter med cloud ekspertise, og spurt dem om fordeler med skyløsninger og hensyn som bør tas.
Bladene på trærne har fått vakre, fine høstfarger. Høsten er endelig her og vi er nå i oktober måned. For oss er det et sikkert høsttegn at vi også er inne i sikkerhetsmåneden. I Knowit er vi nå inne i cloud-måneden, eller "cloudtober" som vi kaller det, og det er ikke tilfeldig at dette sammenfaller med den nasjonale sikkerhetsmåneden. I det moderne IT-landskapet kommer vi ikke unna verken sikkerhet eller sky, og man er nødt til å se disse i sammenheng. Spesielt sikkerhet og sky i kombinasjon med personvern er noe som opptar mange, og her ser vi at mye fortsatt er i endring. For oss som jobber med personvern og informasjonssikkerhet er det ikke mulig å diskutere amerikanske skytjenester uten å nevne hvilke overordnede føringer som er aktuelle. Vi bringer en kort oversikt over de nyeste bitene i dette puslespillet og forklarer hva det betyr for deg.
Velkommen tilbake! Vi håper at alle har hatt en fin sommer! Her er et utvalg av noe av det de fine menneskene i Knowit har drevet med i det siste.😎
Design av systemer er et relativt ungt yrke og ble (slik jeg ser på det) i sin tid skilt ut fra systemutvikling. På 80-tallet før World Wide Web (WWW) var det få spesialistroller innen systemutvikling. Det fantes da få, om noen i det hele tatt, systemarkitekter, informasjonsarkitekter, interaksjonsdesignere, tjenestedesignere o.a. Man var systemutvikler og gjorde alt som var nødvendig for å ferdigstille det ønskede systemet.
Earlier this year I was lucky enough to pass a computer related exam. What you probably
don´t know, is that passing the exam involved a crime. A crime of which I was the victim.
Denne sommaren har 26 studentar vore så heldige å få jobbe i Knowit i Oslo. Me har hatt ulike stillingar og kundeprosjekt, og me har vore innom ulike teknologiar og utviklingsmetodar. Dette har gitt oss eit innblikk i kvardagen som konsulent i Knowit.
I have for most of the days, hours and minutes since 12th March 2020 stayed at home. Working, playing, reading, watched too many tv-shows, read a couple of books and so on…
Knowits sommerprogram er mer populært enn noen gang, og det har aldri vært så mange søkere som i år. Spennende prosjekter, fagarrangementer og sosiale aktiviteter er noe av det årets studenter kan se frem til i løpet av sommeren.
Hvert år søker Knowit etter studenter til sitt sommerprogram ved kontorene i Oslo og Bergen. De siste ukene har Knowit hatt onboarding av studenter fra forskjellige utdanningsinstitusjoner rundt omkring i landet. Årets gruppe består av studenter fra blant annet informatikk, dataingeniør, datateknologi, DigØk og design. Det er god spredning på læresteder og studentene kommer fra mange forskjellige studieretninger.
(Fra venstre): William Andersson, Adrian Pleym, Marie Heggebakk, Tonje Løfqvist, Ahlam Aatif
Oslo Pride har blitt arrangert årlig siden 1974, og tradisjonen tro er programmet spekket med underholdning, musikk og aktiviteter. Festivalen anses å være Norges største og viktigste feiring av skeiv kjærlighet og mangfold, og selv om man i år også må ta hensyn til Covid-situasjonen, er det tydelig at den engasjerer både liten og stor.
Daniel Horn, rekrutteringsansvarlig for Objectnet i Knowit Solutions, skal sammen med surf rock bandet sitt Baja Bug spille konsert på Pride. Det handler om å få lov til å spille musikk for folket, men kanskje enda viktigere, et bevisst valg fra deres side om å støtte mangfold og likeverd.
Skrevet av Frida Strøm Anthonisen og Benita Haftorn Hildonen.
Den tradisjonelle organiseringen i et konsulentfirma er hierarkisk. Må vi ha det slik, eller er det mulig å utfordre dagens strukturer? Vil selskapet stoppe opp dersom man fjerner ledelsen? Er det avgjørende for selskapets suksess at man har en ledelse som løfter blikket, styrer retning, tar hånd om de ansatte? Trenger vi dedikerte ressurser med overordnet ansvar som kan etablere, forvalte og videreutvikle strukturen i selskapet?
This article was first published on LinkedIn October 24, 2016.
Nå er endelig sommeren her og vi nyter varme og lyse dager utendørs.🌞🌡La oss ta et tilbakeblikk på hva de flotte menneskene i Knowit har drevet med denne våren.
De fleste av oss kjenner til karakteren Pippi Langstrømpe fra barndommen. Pippi, «den sterkeste pike i verden», er hovedpersonen i en serie barnebøker som vakte både begeistring og debatt. Det var nemlig lite som var «vanlig» med Pippi, spesielt ikke på 40-tallet da de første bøkene kom ut. Mange tolket karakteren som gal, lovløs, rappkjeftet, vilter og full av fantasi - kontroversiell og radikal for sin tid. Men selv om Pippi er frekk og rebelsk, er hun det på en sjarmerende og inspirerende måte.
Begrepet «fail safe» innebærer at feil ikke skal føre til fare. Det motsatte av «fail safe» er «fail open», det vil si at feil kan føre til fare.
Kan et gammelt, akterutseilt direktorat inspirere til hvordan vi kan organisere innbyggertjenester på tvers av sektorer og forvaltningsnivåer? Kanskje?
Innlegget er skrevet av Trygve Bjørnstad og Camilla Krogstad Grøneng.
Vi kjenner alle til Netflix, et skoleeksempel på vellykket disrupsjon av filmutleiebransjen. Netflix holdt opprinnelig på med utleie og salg av én og én film på DVD (sendt ut til kundene via post), men tok likevel sjansen på å satse på streaming, til tross for at dette potensielt var i konkurranse med kjernevirksomheten. Nå tror vi ikke at Netflix ville tatt i en DVD med ildtang lengre, og i dag selger de deg heller tilgangen til et helt bibliotek med filmer og serier. Med denne forretningsmodellen når de ut til flere kunder og har et sterkere merkevarenavn enn noensinne. Netflix har klart det mange drømmer om – de har funnet nøkkelen til fremtiden, blitt mer lønnsomme og mer verdt som virksomhet og merkevare, og fått en verden full av fornøyde kunder.
En kald vinterdag i februar 2021 står jeg på togperrongen ved Oslo S. Sekken er fylt av det jeg finner mest nødvendig for øyeblikket: turutstyr, en høyttaler, lys og flammer, en gitar og en MacBook. 18 kg til alle slags klima- og værforhold. Gjennom store deler av coronapandemien har jeg bodd aleine i ei leilighet på Grünerløkka. Et forgylt fengsel på 54 kvadratmeter langt unna minnene om et luftig barndomshjem på kysten av Trøndelag. Jeg har vært mye frustrert det siste året og har innsett at jeg ikke kan fortsette å leve sånn.
The term IoT (Internet of Things) has been around for a while. I still remember when I moved from the world of electronics and Industrial Automation to the world of internet connected devices. I struggled to catch the differences between the old M2M (Machine to Machine) and the new trendy IoT technologies. Which applications fall under one domain and which under the other? Over time I learned this is not a zero-one kind of question, but a topic more suited for a Friday-beer with colleagues, rather than a substantial classification.
This article was first published on LinkedIn October 24, 2016.
”Alle” har erfaring med prosjektlederrollen. Prosjekteieren derimot, er oftere fjernere fra prosjektet og mer usynlig for de fleste – dessverre. I dette innlegget deles tanker og praktiske erfaringer rundt prosjekteiers betydning for prosjektsuksess.
We have left 2020 behind us and are already well into 2021. April is here and we are heading towards spring, which means sunshine, longer days and brighter times. What's better than a quick recap and reflection back at what people of Knowit have been up to this winter! ☃❄
I mine seks år som native iOS apputvikler har jeg opparbeidet meg en god slump erfaringer med hvordan denne plattformen fungerer, og jeg anser meg selv som dreven nok til å kunne analysere og gjenskape de fleste elementene fra andre apper. Men hva er en app uten en backend? Jeg kan godt forsøke å gjenskape iOS-appene til Facebook, Snapchat, DnB og Slack, men de vil jo naturligvis ikke fungere uten å være del av en større tjeneste slik at appen kan kommunisere eksternt.
In a user interview you are looking for user stories. To get to drill down to the root of a problem or underlying reasons for doing tasks, it is often suggested that you repeat asking why 5 times. As this Wikipedia article states, the “5” / “five” in the name derives from an anecdotal observation on the number of iterations needed to resolve the problem.
A fictional interview gives insight into
the work of the Architecture Board
De siste årene har det vært veldig mye snakk om at alle ledere måtte skaffe seg digital kompetanse. Vi har utviklet lederprogrammer og kompetansehevingskonsepter over en lav sko, for å sikre at alle ledere kunne nok om den digitale verden til å kunne ta gode beslutninger og hjelpe virksomheten til å utvikle seg digitalt.
Bloomberg kunne i mars i år avsløre et cyberangrep som ga hackere direkte tilgang til videostrømmer fra 150.000 internett-tilknyttede videokamera fra oppstartsselskapet Verkada. Angriperne har demonstrert at de har tilgang til direkte videostrømmer, lagrede opptak og til og med root-tilgang til operativsystemet i hvert kamera. Selskaper som er berørt omfatter ifølge Bloomberg blant annet Tesla, Cloudflare, sykehus, politistasjoner, fengsler og skoler.
By Benita Haftorn Hildonen and Andreas Faafeng
In 2004 Bill Gates famously predicted the death of passwords. Almost two decades later the migration away from password-based authentication to more secure alternatives on the web remains slow. The industry’s main response has been technical solutions such as multi-factor authentication using one-time passwords (OTP), or codes delivered with SMS. Selected sectors such as finance and health care has resorted to hardware-based solution, an expensive exception not within reach for the average service provider.
Knowit lanserer ZIZR – en skybasert tjeneste som gjør det enkelt å finne riktig størrelse på nett.
Da jeg startet å jobbe i Knowit for ca. et halvt år siden begynte jeg ikke bare i ny jobb, men også på reisen fra å være prosjektleder til å bli virksomhetsarkitekt. På denne reisen har jeg oppdaget flere ulikheter i hvordan man tenker og jobber i rollene. Samtidig har det blitt tydelig hvor viktig det er at disse to rollene jobber godt sammen for at virksomheten skal lykkes med digitalisering. I denne bloggposten utforsker jeg ulikhetene og reflekterer over hvordan man sikrer et godt samarbeid mellom prosjektledere og virksomhetsarkitekter.
Nasjonal sikkerhetsmyndighet (NSM) har en egen podcast med mange interessante og relevante diskusjoner om samfunnssikkerhet. I episode 107 fra 18.februar 2021 tar de opp nok et viktig tema: Hvordan skal offentlige myndigheter kommunisere med innbyggerne på en sikker måte? Asker kommune nevnes som er eksempel med dårlig praksis, men hvordan står det til i landets største kommuner?
This article was first published on LinkedIn October 16, 2016.
Det å gjennomføre et digitaliseringsprosjekt eller en digital transformasjon i en virksomhet kan sammenliknes med en familie som skal flytte og kjøpe et nytt hus. Det er mange likhetstrekk som er sammenfallende, og mye handler om håndtering av fornuft og følelser, der vi både gleder og gruer oss, er skeptiske og optimistiske. Det er viktig at alle som blir berørt, blir hørt og opplever at de blir tatt med på reisen.
Jeg har holdt øye med programmeringsspråket Go, eller Golang som det ofte skrives hvis du vil at Google skal skjønne hva du prater om. Språket har vokst eksplosivt de siste årene og har tatt en posisjon som standardspråket for infrastrukturverktøy. Docker og Kubernetes har vært bjellesauer for språket og viser at Go kan takle komplekse oppgaver. Nå er det på tide å se og føle litt på kroppen hvordan det er å løse oppgaver med Go.
Dette blogginnlegget er skrevet for deg som lurer på hva Knowit gjør av smidig metodikk, forvaltning og utvikling, også kalt “Agile Devops”.
Heidi Hundåla er Senior prosjektleder hos Knowit Solutions
Jeg har intervjuet to gode kollegaer som jobber hos to av våre kunder som illustrerer hvordan “Agile Devops” fungerer i praksis.
Utviklingen av samfunnet i dag fører til stadig nye behov og ønsker om konstant forbedring av applikasjoner på nett og bedre sikkerhet. Knowit hjelper deg og din bedrift med å få dette til, men hvordan gjøres det i praksis?
Mange bedrifter velger skyteknologi for å dekke behovene sine. Med skyteknologi går utvikling til produksjon raskere. Utfordringer til drift, som for eksempel god ytelse ved økning i antall brukere, innkjøp av servere, “Single Sign-on” eller backup, slipper man å tenke på. Dette er typiske fordeler man får automatisk ved å velge en skyløsning for applikasjonene/tjenestene/produktene dine. Knowit kan bistå på alt av skyløsninger enten de kommer fra Azure, Google eller Amazon. Knowit satser på sky og utdanner et stort antall teknologer samtidig som flere jobber med dette i dag. Skyteknologi er ingen forutsetning for å levere smidig og kontinuerlig, men det gir en teknisk fordel i mange sammenhenger i dagens teknologimarked.
Smidig prosjektorganisering (Agile) handler om å få produsert én del av produktet, bit for bit, — til produktet fungerer bra i produksjon uten for mye planlegging (*).
Med “Devops” (**) får man ny funksjonalitet og forbedring raskere ut i produksjon fordi reelle brukere er viktige kilder til forbedring. De gir oss det vi trenger i utviklingsteamet.
Med “Agile Devops” organiseres teamet best mulig slik at vi virkelig minimerer tiden det tar fra en funksjonell forbedring er oppdaget til at den er i produksjon. Prosessen må med andre ord gi mulighet for rask tilbakemelding fra bruker til utvikler.
Utviklerne lærer fortløpende hvilke konsekvenser ny funksjonalitet og forbedringer får i produksjon og kan kontinuerlig forbedre sin egen kode og prosesser relatert til å få ut endringer (som f.eks. bedre automatiske tester) og gir derav brukerne det de vil ha før de blir lei av å vente, for eksempel bedre menyvalg eller at applikasjonen ikke virker i IE 11 (nettleser).
Med alle disse forutsetningene har vi mulighet for en effektiv organisasjon rundt applikasjonsutvikling og som er med på å øke “speed-to-market” (***).
Per i dag har Knowit flere konsulenter i en større norsk bank hvor de har utviklet mange tjenester til rådgivere, service-senter og kunder. De driver med Agile Devops. Funksjonalitet flyttes fra en stor monolitt til uavhengige skytjenester i en lokal sky, som for eksempel søknad på forskjellige typer lån, søknad på kredittkort og regionsperre på kort. Disse tjenestene har blitt forenklet, automatisert og er programmert som løst koblede mikrotjenester. Organisasjonen av utviklingsteam speiler behovene til forretningssiden, hvor for eksempel forsikringsavdelingen og avdeling for daglig bank har hvert sitt team. Våre konsulenter jobber i kredittbank-teamet og jeg har snakket med teamleder der.
I banken driver teamene med Scrum eller Kanban (****), men det varierer hvor autonome de er, da det spriker i erfaring og tverrfaglighet. Uten tverrfaglighet blir de avhengig av andre for å få sine leveranser i produksjon. Teamlederen fra Knowit sier de har tilgang til alle miljø og slipper venting på drift eller interessenter. De har frihet under ansvar.
Hele den tekniske strukturen i banken er tilrettelagt for at mange kan produksjonssette samtidig. Ingen springer i beina på hverandre. Provisjonering av nye applikasjoner og miljøer er automatisert. Applikasjoner i form av mikrotjenester er mindre spesialiserte enheter. Dette blir sett på som viktig for å kunne levere raskere. Tidshorisonten reduseres siden det er enklere å sette opp, dermed går hyppigheten opp. De er i dag på flere releaser i uken. Forsetter det slik, blir det daglige releaser.
Forretningssiden gir tilbakemelding til teamene om at de er veldig fornøyde med hastigheten det tar fra krav oppstår til de er ute i produksjon. Sammenlignet med før i tiden, med en vannfallslignende utviklingsprosess, ser de en stor forbedring i “speed-to-marked” i tiden det tar å få tjenestene levert ut i produksjon.
En utfordring de har er at de ikke følger Scrum-regelen på maks 9 på teamet. De har hatt et problem med at det ble altfor mange deltagere i ett team, noe som blant annet førte til at stand-up-møter ble til lange statusmøter. Dette er et typisk problem i utviklingsprosjekter uavhengig av sky og devops. Da kan løsningen være å dele opp i to mindre team og heller la “Scrum Master” for hvert team snakke sammen.
På grunn av automatisering, takket være skytjenester, er driftskostnadene redusert. Utviklingsteamet har tilgang til alle miljø og teamet gjør alt selv, for eksempel å spinne opp et nytt testmiljø. God grunndesign på organisasjon og det tekniske gjør at rettighetene til et team speiles i tilganger til logger og overvåkning, slik at man slipper å stoppe opp i en feilsøking, for eksempel, på grunn av manglende tilgang.
Skytjenestene gjør det enkelt å måle hvordan tjenestene går i produksjon og testmiljø, noe som gjør at utviklingsteamet selv fanger opp kapasitetsproblemer og fikser dem før brukerne varsler om problemer, såkalt proaktiv overvåking. Med så mange mikrotjenester som skal snakke sammen så har teamet fokus på god testdekning med automatiserte tester som oppdateres jevnlig. Teamet benytter også testing i produksjon og for dem er dette hverdagen siden testmiljøer rett og slett ikke dekker alt som ligger i ymse bank-kjerne-systemer.
Hver fredag har de demonstrasjon av det nyeste for forretningssiden og interessenter for å vise progresjon og få raske tilbakemeldinger.
Sikkerhet er innbakt i den daglige jobben til utviklerne. Videre har de automatisk sikkerhetstesting og regelmessige penetrasjonstester. Dette er vi i Knowit vant med å ha søkelyset på i prosjektene våre.
Knowit har en rekke konsulenter i forsikringsbransjen, deriblant et stort selskap som spenner over mange land. Her driver de også med Agile Devops. Ett team leverer verktøy for at skadebehandlere kan gjøre jobben sin på en god og effektiv måte. Det kan være registrering, behandling, utbetaling eller tilrettelegge for partnertjenester som f.eks. leiebil ved uhell. Også her har de en monolitt de jobber med å flytte ut i skyen, men mye blir fremdeles gjort som en del av monolitten. Det er ikke alt som passer til å flytte i skyen enda på grunn av avhengigheter. Kodebasen i monolitten er over 15 år gammel. De jobber med Windows-applikasjoner, web-applikasjoner og flere forbedringer på backend (kjernefunksjonalitet). Teknisk gjeld og forbedring av kodekvalitet inngår som en naturlig del av oppgavene deres . Organisasjonen av utviklerne speiler delvis avdelingene og noen team er crossover. På fire av teamene er Knowit-folk teamledere og jeg har snakket med en av dem.
Mange av teamene på forsikringsselskapet bruker Scrum eller Kanban, men autonomiteten varierer. Det er forskjellig kultur i teamene. Teamleder fra Knowit sier de har et smidig forhold til smidig. Ingenting følges slavisk. De bruker ikke stand-up om de føler at det ikke gir dem noe tilbake. “Scrum Master”-rollen, estimering og sprinter har de forkasta. I stedet har de beskyttende ledere over dem som tar vekk støy når det trengs og de leverer kode til produksjon fortløpende. De kjører Kanban-ish, siden de opererer med flere oppgaver om gangen enn de grensene som Kanban setter.
Teamet ble tidligere avbrutt av interessenter som ba om funksjonalitet som ikke var i oppgavelista, hvor teamleder ga saken videre til lederne over og ba om at dette kommer den rette veien, via prioritering. Det er viktig å la folk være i fred på teamet. Da øker trivselen og produktiviteten. Oppgavene blir prioritert fortløpende av produkteier og teamleder, som er gode til å samarbeide. Teamet er tverrfaglig og består av utviklere, forretning, testere, og ux. De har mandat til å foreslå forbedringer og de får støtte av lederne til dette. De får sjelden nei. Dette er løsningen og sukesskriteriet for at teamet skal få arbeidsro og at oppgavene blir gjort.
Små endringer levert til produksjon gir liten risiko. Kontinuerlig oppdatering av automatiske tester gjør at de er trygge på at det går bra. Gjennom retrospektivene sine endrer de sin egen prosess og vil, hvis det skulle trengs, innføre “Scrum Master” igjen som rolle.
Når en oppgave plukkes opp har utvikler ansvar for den helt til den er i produksjon. Alle på teamet ønsker å levere kvalitet, dette er en viktig kultur å bygge på. Hvis forretning ønsker en høyt prioritert endring, er det ofte et krav at forretning har testkapasitet før oppgaven i det hele tatt startes på. Utvikler skal slippe å vente. Hvis den er viktig, forplikter bestiller seg til å verifisere endringen omgående. Det skal ikke være noe “neste uke”. Hvis det ikke er klart, er det ikke vits i å starte på oppgaven. Det er viktig for utvikler å få rask tilbakemelding.
Teamet har god kontakt med brukerne og tar hensyn til måten de jobber på når de utvikler nye tjenester. Utviklingen skal støtte det faktum at måten skadebehandlerne jobber på har endra seg de siste 15 årene. De endrer hele kjernelogikken.
De har også testere på teamet som fortrinnsvis skriver tester med en gang oppgaven defineres og som trykker på alle knapper som ikke skal trykkes på. Både testere og utviklere har ansvar for å oppdatere automatiske tester som i neste omgang er med på å minske risiko for feil i produksjon. Skytjenestene gir mye gratis, hvilket hjelper på hastigheten. Disse faktorene er med på å forbedre “speed-to-market”.
For en del år tilbake var det vanlig å levere “Big bang” fire ganger i året på monolitten. Da var det mye som kunne gå galt og helgejobbing måtte tas i bruk. Dette har gradvis endret seg fra fire ganger i året - til en gang i måneden — til omtrent hver dag. På stand-up er standardspørsmålet “hva hindrer oss i å gjøre deploy i dag?”.
Kulturen teamet har nå med å ta ansvar fra A til Å har ikke passet alle på teamet alltid. Det har tatt tid å innføre. Endringer på den tekniske siden kan være rett frem, men å endre måten de jobber sammen på er ofte en utfordring.
De demonstrerer funksjonalitet for interessentene fra tid til annen, men teamleder innrømmer at dette er et forbedringspunkt. De må ha det oftere. Det er viktig med demo jevnlig for å holde interessentene oppdatert på status og for å unngå unødvendige spørsmål til utviklerne. I tillegg er det bra for deling av kunnskap innad i teamet, “hvordan virker siste nytt i praksis?”
Det finnes mange gode prosesser for GDPR og generell sikkerhet i selskapet, blant annet prosesser for å godkjenne applikasjoner i skyen. Teamet føler seg veldig trygge på at de ikke setter sikkerhetshull ut i produksjon.
Selv om kontinuerlige leveranser og smidig metodikk er vanlig i dag, er det likevel mange bedrifter som ikke får til dette. Utviklere opplever til stadighet å bli avbrutt med nye funksjonalitetsønsker og de må ta i bruk overtid for å bli ferdige med planlagte oppgaver. Teamkultur med frihet under ansvar er særdeles viktig, og i dette inngår aksept fra forretningssiden for at oppgaver tar tid å løse. Dette har begge team jeg har beskrevet her.
Bedriftene har ofte ikke testmiljøer eller såkalte staging-miljøer (et miljø som ligner på produksjon), og kvaliteten på det som leveres blir dårlig. Å bruke skytjenester gjør det lett å kunne spinne opp de miljøene de trenger. Automatiske tester og tid til å definere dem, slik de har i begge eksemplene her, er viktig for å få til kontinuerlig produksjon. Å ha tverrfaglighet på teamet, som aktive produkteiere og egne testere er helt klart et fortrinn i kvalitet og brukbarhet i produksjon, — man får reell gevinst. Venting gjør folk demotiverte. Unngå det. Og ha demo.
Den tekniske og det organisasjonsmessige er like viktig.
Et sluttpoeng er at om man ikke har oppnådd sitt fulle potensial selv om man har innført smidige ritualer og prosesser, kan være nyttig å snakke med en profesjonell som Knowit. Vi kan hjelpe til som nøytral part for å løfte teamet videre. Sånn oppstår det enda bedre verdiskapning og teamets tilfredshet øker.
(*) Definisjonen på “bra” kan variere, men per i dag anbefaler de fleste “Minimum Valuable Product” eller som jeg har vært med på: “Walking Skeleton”).
(**) Devops = Development + Operations, utvikling + drift, - det vil si utviklingsteamet gjør utvikling og drift.
(***) “Speed to market” er det samme som “Time to Market” og betyr tiden det tar fra de første ideene rundt et produkt oppstår og dets eventuelle tilgjengelighet på forbrukermarkedet. Bedrifter bruker beregning av time-to-market for å evaluere hvordan produkter utvikles og hvordan ett bestemt prosjekt håndterer ekstern konkurranse.
(****) Kanban er en måte for å begrense igangsatt arbeid i en produksjon. En ny jobb må vente hvis antall påbegynte jobber har nådd en grense. Så snart en jobb er ferdig, kan neste ventende jobb settes i gang. I tillegg har man en tavle med oppgaver, styring av arbeidsflyt, tydelige regler, hyppige tilbakemeldinger og kontinuerlig forbedring gjennom samarbeid, utvikling og eksperimenter.
Scrum er et rammeverk for å utvikle informasjonssystemer. Scrum-prinsippet bygger på samarbeide innenfor team fra tre til ni medlemmer som bryter ned oppgaver til prosjekter som kan ferdigstilles innen gitte tidsrom, såkalte «sprint», som vanligvis strekker seg fra to uker til én måned. Metoden omfatter også daglige vurderings- og planleggingsmøter som ikke skal vare lenger enn ett kvarter.
Phew, we can all agree that this year feels like it has lasted way too long. Luckily, we’ve only got a month left of it! If you’re bored of Lockdown 2.0, have a look at what people of Knowit have been up to this autumn 😁!
Siden viruset fortsatt setter begrensninger for å møtes fysisk ble denne månedens Quality Day helvirtuell. Heldigvis er entusiastene like motiverte og siden mange nå kjenner på det å sitte hjemme og jobbe hele tida, var vi nærmest fulltallig da dagen begynte med en felles sesjon på Teams.
Database code. Queries, updates, and deletes. Repositories. Like many other developers, I have struggled with these things that tend to end up rather ugly. Not only might there be a lot of programming language (SQL) embedded inside another programming language (your app’s code), but there are a lot of mappings back and forth for data types, integration code, boilerplate! Or, you might be one of the lucky ones who get to use an Object Relational Mapping-library, clean, simple, and elegant code, right, hiding all of the interesting details? This post is about the quest for the Right Abstraction.
Strikkekampanjen oransje skjerf har blitt arrangert over hele landet de siste 10 årene, som et symbol på ønsket om et varmere og mer inkluderende samfunn. I år fungerer strikkedugnaden litt annerledes, og Kirkens Bymisjon har oppfordret til å bruke plaggene eller gi dem bort til en god venn, for å sette søkelys på ensomhet.