All kode som eies og forvaltes av offentlige virksomheter bør være åpen, med noen veldig få unntak. GOV.UK har siden 2012 hatt coding in the open som standard, og man må argumentere hvis man ikke ønsker å åpne koden. Nå er det på høy tid at norsk offentlig sektor også tar steget!

Åpen kildekode vs åpent tilgjengelig kode

Målet er at all offentlig kode skal være åpent tilgjengelig (coding in the open). Kildekoden publiseres og forvaltes som åpen kildekode, og bruker den tilhørende infrastrukturen og mekanismene. Imidlertid er etablering av et langsiktig bærekraftig nettsamfunn (community) ikke nødvendig i denne sammenhengen. Ansvaret for videreutvikling og forvalting vil uansett ligge hos den offentlige virksomheten. Hvis man i tillegg klarer å etablere et åpent kildekode-nettsamfunn, er det å betrakte som en bonus.

Hva skjer i resten av verden?

I Storbritannia snakket GOV.UK allerede i 2012 om «Coding in the open», og understreket forskjellen mellom åpen kildekode og åpent tilgjengelig kode.

We tend to talk about that as Coding In The Open rather than Open Source. Partly because we're not currently in a position to build and support a community around that code, and partly because most of it's so tailored to our system that we're not sure how useful it will be to others right now. But rest assured, if you see something useful you can use it - it's published under an MIT licence

Code for America startet allerede i 2009 og forvalter flere hundre åpne produkter på GitHub. EU-kommisjonen lanserte nylig sin plan for å forvalte sine produkter som åpen kildekode. Beslutningen lener seg på en undersøkelse som peker på teknologiuavhengighet, konkurransekraft og innovasjon.

Her hjemme har Digdir ingen tydelige føringer på dette området (men flott at Altinn3 er åpen kildekode). Arkitekturprinsipp 5 - Del og gjenbruk løsninger bør komme med en tydelig anbefaling. Arkitekturprinsipp 6: Lag digitale løsninger som støtter samhandling, nevner bruk av åpen kildekode: «6.9Vurder bruk av åpen kildekode fremfor lukkede, kommersielle løsninger». Også i Digitaliseringsrundskrivet –regjeringens sammenstilling av pålegg og anbefalinger om digitalisering i offentlig sektor – glimrer åpen kildekode med sitt fravær.

NAV sørger nesten på egen hånd for at det ikke er helsvart på hjemmebane. Inspirert av GOV.UK har NAV tydelige retningslinjer for å forvalte kode åpent tilgjengelig. Det vises også godt på GitHub, der NAV IKT har over 1000 prosjekter. Skatteetaten ligger litt etter i løypa, men er på gang og lanserte nylig en rekke produkter som åpen kildekode.

10 grunner til at all offentlig kode bør være åpen

#1 Finansiert av offentlige midler

Utviklingen av produkter og tjenester i offentlige virksomheter er finansiert med fellesskapets midler. Det er med andre ord bygget med innbyggernes midler, og bør være åpent tilgjengelig for oss.

#2 Offentlige virksomheter er monopolister

Store deler av offentlig forvaltning møter ikke konkurranse. Eksempelvis er det ingen konkurrenter innenfor innkreving av skatt, tildeling av studielån eller foreldrepenger. Det er med andre ord ingen forretningshemmeligheter, og kildekoden bør derfor være åpen.

#3 Kode er implementasjon av regelverket

Systemene som lages av offentlige virksomheter speiler lover og regler som virksomhetene forvalter. Selv om abstraksjonsnivået og omfanget er ulik, er kode og regelverk prinsipielt to sider av samme sak. Begge deler bør være åpne.

Både regjeringen og Digdir har initiativer for «Klart og digitaliseringsvennlig lovverk». Noen drømmer attpåtil om å skrive lovene våre som kode.

#4 Offentleglova – transparent offentlig forvaltning

Offentleglova heter egentlig «Lov om rett til innsyn i dokument i offentleg verksemd». Den er grunnlaget for at alle skal kunne ettergå beslutninger og vedtak i offentlig forvaltning, og brukes mye av journalister. Intensjonen til offentleglova samsvarer veldig godt med åpen offentlig kildekode:

Formålet med lova er å leggje til rette for at offentleg verksemd er open og gjennomsiktig, for slik å styrkje informasjons- og ytringsfridommen, den demokratiske deltakinga, rettstryggleiken for den enkelte, tilliten til det offentlege og kontrollen frå ålmenta. Lova skal òg leggje til rette for vidarebruk av offentleg informasjon.

#5 Åpen kildekode er godt personvern

Personopplysningsloven understreker flere steder at behandlingen av personopplysninger må fremstå som åpen og forståelig. Ved å åpne kildekoden ville alle kunne se hvordan data blir behandlet, hvilke grep som er gjort for å sikre systemet og data, og hvordan eksempelvis innebygd personvern er gjennomført i praksis.

#6 Synlighet vil gi bedre kode

Åpen kildekode vil fremme kvaliteten. Når man vet at det man lager er synlig og tilgjengelig for alle, vil man i større grad bry seg om kvaliteter som lesbarhet, forvaltbarhet, sikkerhet og testbarhet.

Anna Shipman i GOV.UK skriver også om denne effekten:

It encourages good practice
When you know someone is watching, you tend to take greater care. You're more inclined to document your work clearly. You make sure your code is secure by keeping secrets separate from the code. You are polite and constructive in code reviews, and you follow good architectural principles.

In short: when other people can see your work, you tend to raise your game.

#7 Flere øyne finner flere feil

Linus’ lov sier at «given enough eyeballs, all bugs are shallow»: Jo flere som jobber med en kodebase, jo flere feil vil de finne. Påstanden er omstridt, og eksempler som Heartbleed og Log4Shell viser med all tydelighet at det ikke finnes noen garantier. Imidlertid er det indikasjoner på at populære åpen kildekodekomponenter mottar flere feilrettinger enn mindre populære. I alle tilfeller gjør åpent tilgjengelig kode det mulig for alle som er interessert å gjøre kodegjennomganger.

#8 Gjenbruk

Gjenbruk er ledergruppas våte drøm og teknologenes mareritt. Rett nok brukes og gjenbrukes en rekke plattform- og infrastrukturkomponenter. Når koden blir spesifikk for forretningsdomenet, blir gjenbruk vanskeligere. Det er lettere å bruke NAV sin nais-plattform enn å gjenbruke beregning av sykepenger. Gjenbruk kan betraktes som en bonus, spesielt for domenespesifikk kode.

Dette er også grunnen til å vektlegge åpent tilgjengelig kode framfor åpen kildekode med et levende nettsamfunn. Men gjenbruk kan allikevel forekomme. Det er ikke lenge siden jeg plukket opp at en kollega hadde tatt i bruk en funksjon som Kartverket publiserer åpent. En sekundæreffekt er at andre virksomheter kan la seg inspirere av og bruke løsningsmønstre som er åpent tilgjengelig.

#9 Gratis håndtering og tjenester

Mange tjenester tilbyr gratis eller redusert pris for åpen kildekode. Noen eksempler er GitHub, Snyk og DataDog. Her er en lengre liste.

#10 Økt konkurranse og attraktivitet

Åpent tilgjengelig kode kan bidra til å øke konkurransen. Konsulenttilbydere får mulighet til å sette seg inn i eksisterende kodebaser, og dermed få et vesentlig bedre grunnlag for å levere tilbud og folk. Tilgang til kodebasen kan også bidra til å påvirke hvor attraktiv en arbeidsgiver er, både for innleide og ansatte.

Sikkerheten må røktes i hele livssyklusen

Åpent tilgjengelig kode eksponerer en ny angrepsflate og gjør det lettere å finne sårbarheter. Angripere får kortere vei til svakheter i kode og tredjepartsbiblioteker. Sikkerheten må derfor røktes fra vugge til grav for alle systemer virksomheten har ansvar for.

Dette ikke er unikt for åpen kildekode. Nærmest daglig rapporteres det i nyhetene om innbrudd, lekkasjer og utpressingsangrep, uavhengig av hvordan koden forvaltes. Sikkerhet er obligatorisk i hele livssyklusen for alle systemer i den digitale tidsalderen. Security by obscurity vil aldri være tilstrekkelig.

Her er de viktigste anbefalingene:

Etabler en sikkerhetskultur. Når alle team-medlemmer tar eierskap til og er observante på sikkerhetsutfordringer i det daglige arbeidet man gjør, da har man en fungerende sikkerhetskultur.

Hemmeligheter må ligge utenfor kodebasen. Passord, nøkler og sertifikater skal aldri forvaltes sammen med koden.

Slett eventuelle personopplysninger, eksempelvis test-data. Det er sannsynligvis ikke lov å forvalte personopplysninger i kodebasen uansett, men de må i alle fall ikke gjøres åpent tilgjengelig.

Gå gjennom og/eller slett historikk når lukkede kodebaser åpnes.

Bruk av tredjepartskomponenter er en kost/nytte-øvelse. Gjør en reell vurdering av community, modenhet, aktivitet og kvalitet. Foretrekk komponenter som har få avhengigheter; man har ansvaret for dem også. Hold avhengighetene oppdatert til enhver tid.

Sørg for innebygd avhengighetssjekk i verdikjeden din med hensyn til utdaterte versjoner og eventuelle sårbarheter, som for eksempel verktøyene Dependabot og Snyk.

Kan all kode være åpent tilgjengelig?

Ja. Med få unntak:

Algoritmer som brukes til å detektere svindel og misbruk.

Kode som implementerer upubliserte endringer i lover og forskrifter. Denne kan åpnes så snart de er behandlet og vedtatt.

Hemmeligheter – nøkler, passord og sertifikater – må som nevnt ikke ligge åpent tilgjengelig.

Dette er en marginal del av totalen, og bør være lett å holde orden på.

All I want for Christmas…

Det er mange fordeler med å forvalte koden åpent. Det finnes flere grunner i tillegg til de 10 i denne artikkelen. EU legger vekt på teknologiuavhengighet, konkurransekraft og innovasjon. GOV.UK peker på bedre samarbeid, læring og deling. Fordelene er mange, og sikkerheten må uansett røktes.

Kjære Digdir, Regjering, Storting og offentlige virksomheter i Norge! Til jul ønsker jeg at vi gjør som GOV.UK og forvalter all offentlig kode åpent tilgjengelig!

P.S. Forfatteren snakket også om dette temaet på JavaZone 2021. Videoen blir tilgjengelig i januar.

Photo by Riku Lu on Unsplash

All offentlig kode bør være åpen

Using the function map to change the elements of a list has become a common pattern in modern programming languages. It is often used in Elm and map is also used in Elm for the Maybe and Result types.  

Using the function map to change the elements of a list has become a common pattern in modern programming languages. It is often used in Elm and writing a function to double all the integers in a list in Elm can be written as such

As expected, running the function doubleInts [1,2,3,4] will return [2,4,6,8]. You might wonder what other types map is defined for in Elm and how they operate.

Maybe


In Elm there is a type called Maybe which is used when a function is not guaranteed to return a proper value. A value of Maybe has two variants, it can either be a value, written

or not a value, written as

To give an example, say you have a String and want to convert it into a Float using the function String.toFloat, the String might not represent a valid floating point number. As such, it's type signature is a String as parameter and Maybe Float as it's return type.

If given the String "0.5"

it will return the value

as "0.5" is a valid floating point number.


On the other hand, if given the string "abc"

the conversion to a floating point number fails and as expected the returned value is

Both these value still have the type Maybe Float as both are valid attempts of parsing a floating point number.


The Maybe type is common in functional programming languages, such as Haskell's Maybe and Scala with it's Option. It is used often in functional programming instead of throwing exceptions and null-values.


The definition of the type Maybe in Elm is:

Mapping a Maybe


When mapping a list, each element is transformed by a given function. In the case of a Maybe, there is either a value or not a value, and can thought of as mapping either an list with a single element or an empty list. You're hoping there's an element inside the Maybe box to run the function on, however, if the Maybe is a Nothing, it will just stay as a Nothing after mapping the function.

How the types change


Even though mapping a function of a Nothing value will not change the value itself, it will still affect the type of the returned Maybe. Say one wants to check if the Float inside is greater than 5 by running

If give an actual value

The returned value still is a Maybe, but it's type has changed from Maybe Float to Maybe Bool.
When given a Nothing

There is nothing to compare to, and as such the returned value will still be

and it's type will be Maybe Bool, as we tried to compare the potential floating point value to 5.


The definition of map for a Maybe is

Result


Similar to Maybe, Elm has a type to represent values that either succeeded or gave an error which is called Result. It has two variants:

and

Defined in Elm as



Given that you want to parse a JSON object as a String, "{ "height": 5}".

and check that the height is higher than 10 we can use map on the Result value

Similar to Maybe

will return 

and

will return 



Here is the definition of map on a Result

Functors


The way map is defined for different types is inspired by the Functor design pattern in functional programming, which in turn is derived from category theory in maths. In general for a value to be a Functor it has have a function map with a type signature map : (a -> b) -> f a -> f b, where f is the type constructor, i. e. Maybe, Result, or List. If a functor maps the identity function, it has to return the functor unchanged.

Mapping more than lists

Contexts in React are great. They provide an easy solution for shared component state, avoiding prop drilling and many other common patterns. All that while being built into React itself. What is not to like about that, and when should we reach for other solutions?

Where context shines: contextual data in the background

Context has a lot of use cases, and it is built into React for good reason. Library authors and users can access the same APIs and can be a lot easier to agree on a solution to a common problem.

Themes and locales

Both themes and locales are great examples of uses for context that affect an entire application. The values are not changed often, and when they are changed the entire app will probably need to be re-rendered with either a new theme or new translations.

Libraries

Library authors can utilize context since it is built right into React. Common uses could be to provide settings to a library like SWR does with Global configuration, which adds a context provider that SWR consumes. Or letting the user access library APIs at the component level such as the React Router hooks API, which exposes parts of the internal React Router context for library users.

Semi-local state

Context is a nice fit for a shared state that is used in small parts of an application as well. An example of this can be wrapping an enhanced form in a context provider to collect all form state. Much in the same way as Formik does. With this use, the context can be very useful without affecting a large part of the application.

Where the performance falls apart

The examples where context works well all have some things in common. They either don't update often, or they affect only a small portion of an application. When we apply a context that changes often to a large part of an application the rendering process can grind to a halt.

To get into why this happens we can take a simplistic look into how context works. To use context we need a context, a provider, and a consumer.


We'll set up a context:

A Provider that we'll put at the top level of our app:


And one or more components that consume the context:


In this case, any component below DataProvider in the component tree can access the context value, such as ComponentA does. This also means that any time the value in DataContext.Provider changes, every component consuming the context will be re-rendered.

Complex states

In real-world apps, data is often not so simple. Our data might end up containing a list of structured objects, and our value might also include more functions for manipulating the state.

Adding multiple values to the context makes this process a bit more complicated. The context value is checked using strict referential equality (===), and to pass multiple values we have to wrap them in an array or an object.


Simple enough, to avoid unnecessary renders we can wrap the object in a useMemo to keep the referential equality:

This approach works well enough. Any part of value that is created in the function body of DataProvider has to be wrapped in a useMemo or useCallback to avoid triggering a re-render of all consumers at every render of DataProvider. If data in this example is a complex object or a long list of objects this can become quite cumbersome.

Consuming only part of a context

When using context as a global store for a specific piece of data we'll usually do it to make it available to many different components in our app. These components will probably end up only needing certain parts of the value in our context.

This is one of the use cases that become a bit harder to solve with context, as React has no way to figure out which part of a context is used by a specific component.

If for example out context data from the previous examples contains a User with an email and a name. We can have two components using different parts of the user object:

Both of these components are subscribed to the same context. This means they will both be re-rendered whenever any part of the context value changes, even though they only use part of the value. As of right now React gives us no way to avoid this behavior.

This example will probably never lead to degraded performance due to excessive re-renders. But adding a bit more complexity to the context value might do. Especially combined with updating the data frequently, such as on changes in a form or on keypress.

Optimizing complex context states

We can do some optimizations to make our application snappy again if many re-renders are triggered by a context, but these optimizations have to be implemented outside of the context itself.

Memoizing child components

The first solution is to wrap child components of the context consumer in React.memo. This will stop the unnecessary re-renders from propagation to children of the component:

Keep in mind that by default React.memo only does a shallow equality check on the props of a component. Objects, lists, or functions as props can lead to memoization never kicking in.

Deferring frequent state updates

The other option is to stop our state and therefore context value to update frequently in the first place. A good place to start can be to debounce or throttle a form or an input. Another solution can be to batch state updates together.

Other solutions and the future

Selecting parts of a context

It would be great if we could subscribe to just the parts of a context. That way many of the performance pitfalls can be avoided. Luckily there is a library for that!

use-context-selector has been available for quite some time. It wraps around a context to enable selection of the part you want:

Not a fan of including a library to do the work?

You might be in luck, as the React team has been experimenting with adding internal support for context selectors. The experiment is currently in a halted state, so I would not get my hopes up for it arriving soon.

useDeferredValue in React 18

With concurrent mode React will enable behavior that can keep the UI responsive while other work is deferred in the background. With useDeferredValue we'll be able to stop changes to the context value from propagating immediately.

This feature has not been released yet, and may not work in all cases.

Should I use context, or should I reach for another solution?

As with all things in this world, it depends on the "context" of what you are doing. The internal context in React works well for a lot of things and is easy to get started with. It is a great first choice if the application doesn't have specific needs.

On the other hand, it tends to not scale well with complex state in larger applications, frequent state updates, and can easily lead to sluggish performance if used incorrectly.

In my personal opinion, I'll continue using context for simple tasks. While relying on libraries for state management in cases where each store has more than a few primitives or single objects.

React Context might not be the right solution for your app

I luke 16 skrev vi om seks ulike hovedkategorier av sirkulære forretningsmodeller. Men hvilke eksempler finnes egentlig? Hvilke selskaper er i dag med på å holde materialstrømmer lenger i verdikjeden gjennom de såkalte reverste syklene? La oss ta en titt!

De seks hovedkategoriene av sirkulære forretningsmodeller er:

Reparasjon og vedlikehold

Gjenbruk og redistribusjon

Renovering og reproduksjon

Resirkulering

Kaskadering og formålsendring

Biokjemisk råstoffekstraksjon

1. Reparasjon og vedlikehold hos Northern Playground

Northern Playground er et norsk “slow fashion”-selskap som selger tidløse og kvalitetssterke basisplagg. Selskapet har som mål å minske nordmenns forbruk av klær. Det gjør de gjennom å oppfordre folk til å bruke klær så lenge en kan, kjøpe kvalitet, kjøpe klær som ikke går av moten og ikke minst reparere klær som blir ødelagt.

Northern Playground tilrettelegger for reparasjon av ødelagte klær på to måter. Først og fremst oppfordrer de kundene til å fikse klærne sine selv. Selskapet tilbyr kundene beskrivelse for reparasjon av hull og småfiks av glidelåser, og sender også kunden det materialet som trengs for å gjennomføre reparasjonen. Dersom dette ikke går, kan kunden også levere sitt Northern Playground-plagg tilbake til butikken og de vil reparere plagget — helt gratis, hele livet.

2. Gjenbruk og redistribusjon med delingstjenesten Hygglo

Hygglo er tjeneste som startet opp i 2016 og som siden den gang har vokst seg til å bli størst i Norden på utleie mellom privatpersoner. Hygglo har som motto at “Ting skal brukes”, og de ønsker å ha en positiv global innvirkning på miljøet gjennom å tilrettelegge for deling av (ofte dyre) gjenstander mellom privatpersoner.

Med Hygglo kan privatpersoner leie ut de tingene de ikke bruker hver dag, samt leie ting selv når de har behov for det. På den måten øker Hygglo bruksgraden til gjenstandene på plattformen, og forhindrer kjøp av nye gjenstander som trolig vil bli brukt svært sjeldent. På Hygglo kan man for eksempel leie toppturutstyr hvis man skal på tur, kamera dersom man ønsker å ta noen ekstra fine bilder en helg eller en feinsag hvis man pusser opp, og dermed slipper man å kjøpe noe som bare vil støve ned i boden mellom bruk.

3. Renovering og reproduksjon av Caterpillar-maskiner

Caterpillar er et amerikansk selskap og er verdens største produsent av bygge- og anleggsmaskiner. Caterpillar-maskinene er lett gjenkjennelige med sin gule farge, men har over tid også blitt kjent for sin forretningsmodell som legger opp til reproduksjon av maskinene. Slagordet til Caterpillar er “Machines that are built to be rebuilt”.

I stedet for å fokusere på å bruke lite materiale inn i produksjonen av maskinene fokuserer Caterpillar på å designe og produsere kvalitetssterke maskiner som det er meningen at skal renoveres eller reproduseres flere ganger i løpet av sitt livsløp. Caterpillar designer sine maskiner på en slik måte at ødelagte komponenter relativt enkelt kan erstattes, og har i dag over 3600 ansatte som jobber utelukkende med dette.

4. Resirkulering og plast som får nytt liv med Aion

På verdensbasis produseres det årlig 260 millioner tonn plastavfall og dette har Aker Biomarine-selskapet Aion lyst til å gjøre noe med. Aion har som mål å bli den ledende sirkulære aktøren innen robuste plastfraksjoner med sin skalerbare forretningsmodell som de beskriver gjennom begrepet “Circularity as a Service”.

Aion sin forretningsmodell er bygget rundt å samle og sortere marint plastavfall, det være seg trålposer eller tauverk, og sende det til de som leverer granulering av plast. Deretter blir dette sendt videre til et støperi som lager produkter av den resirkulerte plasten, for eksempel serveringsbrett eller handlekurver. Produktene blir så sendt ut til kundene der de brukes til de er slitt ut. Når det er tid for å bytte ut produktene, sendes de i retur inn i Aion sin verdikjede, der plasten granuleres og støpes til nye produkter, som deretter sendes tilbake til kunden for runde to. Ved alle stoppestedene henter Aion et datapunkt som samles i en programvareløsning, og slik bygger de opp et solid datagrunnlag for videre utvikling av tjenesten. Aion har kunder som NorgesGruppen, Varner og McDonald’s, der sistnevnte i dag bruker serveringsbrett av resirkulert plast fra havene på enkelte serveringssteder.

5. Kaskadering og formålsendring med Gruten — Oslos sorte gull

Gjennomsnittsnordmannen drikker tre kopper kaffe hver eneste dag, og nordmenn er med det på andreplass over land som drikker mest kaffe i verden. Av det blir det mye kaffeavfall, eller “sort gull” som den norske virksomheten Gruten kaller det. Gruten skaper nemlig nye verdier av Oslos kaffeavfall, og viser med dette hva et sirkulært samfunn kan bety i praksis.

“Kaskadering og formålsendring omfatter forretningsmodeller som benytter biologisk avfall, koprodukter eller biprodukter fra en prosess som ressurs inn i en annen prosess”

Siden 2014 har Gruten brukt tonnevis med kaffeavfall til å lage nye produkter, og de har blant annet etablert Gruten soppfarm, hvor det dyrkes østerssopp på kaffegrut. I 2019 ble ni tonn kaffeavfall gjort om til 1,6 tonn østersopp. I tillegg til østersopp selger Gruten et mangfold av produkter og tjenester, hvor samtlige baserer seg på eller er dyrket gjennom bruk av kaffegrut, som såpe og kroppsskrubb. Gruten tilbyr videre undervisning knyttet til bruk av kaffegrut slik at kundene selv kan lære å oppsirkulere kaffeavfallet de produserer hver eneste dag.

6. Biokjemisk råstoffekstraksjon av matoljen til McDonald’s

Det er ikke bare plastbrettene til McDonald’s som bidrar til økt sirkularitet!

Neste, som er verdens største leverandør av fornybar Diesel raffinert fra avfall, McDonald’s Nederland og logistikkselskapet deres Havi inngikk nemlig et sirkulærøkonomisk partnerskap i 2020. Samarbeidet går ut på at brukt matolje fra produksjonen av pommes frites på McDonald’s-restaurantene skal raffineres og bli til drivstoff som brukes i HAVI-lastebilene som leverer mat til McDonald’s. I partnerskapet har HAVI ansvar for å samle inn brukt matolje fra de 252 nederlanske McDonald’s-restaurantene, som Neste konverteter til drivstoff og leverer tilbake til HAVI igjen.

Parnerskapet baserer seg på den sirkulære grunntanken om å se på avfall som en ressurs som kan brukes om igjen, og som slik minimierer behovet for uttak av jomfruelige ressurser. Denne forretningsmodellen er i aller høyeste grad med på å lukke den sirkulære verdikjeden ved å ta materiale av svært lav verdi og omdanne det til noe som kan brukes om igjen i en ny verdikjede.

Disse seks eksemplene viser hvordan selskaper bidrar til å beholde materialstrømmer lenger i verdikjeden på ulike måter. Det er viktig å påpeke at det ikke finnes noen oversikt bestående av et gitt antall sirkulære forretningmodeller som man kan velge mellom. Det er derimot kombinasjonen av ulike sirkulære varianter av verdiforslag, verdileveranse, verdiskapning og verdifangt som gir ulike forretningmodeller, hvor deler av disse er sirkulære.

Kilder:

https://www.northernplayground.no/

https://www.hygglo.no/

https://www.sustainablebd.com/case-study-caterpillar-remanufactured-and-rebuilt-products

https://www.dn.no/bors/aker-biomarine/aker-biomarine-vil-skille-ut-og-borsnotere-et-nytt-selskap/2-1-930851

https://www.gruten.no/

https://corporate.mcdonalds.com/corpmcd/en-us/our-stories/article/PackagingAndWaste.cookingoil-to-fuel.html

En sirkulær forretningsmodell - hvem har egentlig det?

A user journey canvas to map out your design system as a service, and to focus on some of the parts involved in making it truly valuable for your users.

Like to take the pulse of your design system? Or find out what to focus on when working on a new one?

A good starting point is to map out our service and some of the parts involved in making it truly valuable for your users.

This canvas t is divided into the main phases and subdivided into some of the goals of using a design system:

Learning how to use it

Design with it

Collaborating with others

It is made in Miro, and you can copy and edit to make it your own. It would be fun to learn how to improve the canvas, so any feedback to Sergio.haisch@bekk.no or comment in Miro would be much appreciated.

Link to the canvas in Miro 

Good luck!

23-Dec

Today's posts

All offentlig kode bør være åpen

Mapping more than lists

React Context might not be the right solution for your app

En sirkulær forretningsmodell - hvem har egentlig det?

Design System User journey canvas