Arkitektur A och O med Archade Baseline 2019q3

Företagets Arkitektur finns alltid, det är inget som arkitekten uppfinner;

• Företaget har en struktur
• Företaget har processer och aktiviteter som utförs (eller borde utföras)
• Det finns olika typer av verksamhetsstöd, mer eller mindre digitala

En av arkitektens huvuduppgifter är att beskriva dessa på ett bra sätt; fört när man beskriver kan man förstå och det man förstår kan man utveckla och förändra. När man väl har en beskrivning kan göra flera spännande analyser.

Man kan genomföra Riskanalys på sammansatta delar och inte bara på delarna i sig. I en sådan analys kan man tex se hur ett risk som löser ut för ett system kan sprida sig eller påverka sin omgivning.

Kartan man får fram kommer också att vara ett bra underlag för att jobba med informationsanalyser. Rätt utförd ser man var information finns, var den är digital eller inte, vilka system eller för den delen roller som behöver informationen. Jag har gjort ett par GDPR-analyser med just arkitekturen som underlag – ofta finns det ingen anledning att gå djupare än så och man slipper skapa en process-karta med detaljer som man ändå inte bryr sig om.

Rita eller Modellera

När jag först jobbade med design av mjukvara på 90-talet ritade vi diagram i ordbehandlaren. Det var innan Visio fanns och vi jobbade inte i Windows, vi körde FrameMaker på Sun Solaris workstations. Microsoft hade precis släppt Windows 3.1 och hade en bit kvar till vad Sun OS och OpenWindows kunde erbjuda.

Under min inledande tid som arkitekt på RFV/Försäkringskassan (lösningsarkitekt med dagens nomenklatur) ritade vi all källkod i UML och kodgenererade. Vi gjorde det i Rational Rose och jag valde redan då att sticka och från kollegorna och också jobba med arkitektur i modellform medan kollegorna ritade sin arkitektur i Visio. Jag kunde koppla lösningsarkitekturen till kod-design som andra gjorde, dom kunde inte göra något sådant. Dokument och presentationer skrevs som vanligt, jag klippte bara in arkitekturen.

När jag började på IKEA var det samma resa. Man jobbade med arkitektur i Visio och Excell. Det är verktyg som fungerar men som inte på något sätt ger arkitekten det stöd hen behöver. Även här gick jag min egen väg och jobbade i ett verktyg som är specialbyggt för att rita arkitektur på den nivå som behövdes. Verktyget heter Archi. Jag har i dag ett helt koncept för att jobba med arkitektur kring detta verktyg; Archade Baseline 2019q23. Jag ifrågasätter periodiskt Archi och utvärderar en del alternativ men har inte funnit anledning att byta. Archi är helt enkelt ”spot on”.

Skillnaden mellan att Rita och Modellera är att den som ritar får en bild som beskriver arkitekturen, precis som ett foto. Det är vad många tror att man behöver.

Modellen ger dig också en bild, men där finns en inneboende kunskap också. När man ritar en relation mellan två element finns inte bara ett streck utan en kunskap om att dessa två element har en relation, vilken relation dom har, och på vilket sätt. Med denna kunskap kan man sedan göra analyser.

Den som jobbar med bilder försöker ofta bygga sin kunskap i Excel. Jag har sett mycket komplicerade Excel-diagram för detta som snabbt blir ohanterliga. Att jobba med en bild och Excel separat är blir snabbt en stark felkälla. Är man inte petigt noggrann under arbetet för man in småfel och efter hand är det ett stor-fel.

Den som jobbar med bilder tenderar också jobba på en mer abstrakt nivå, eftersom man saknar stödet för att hantera alla detaljer. En högre abstrakt nivå ger ett ökat avstånd till företaget i övrigt och färre har förmågan att läsa och förstå det arkitekten uttrycker. Detta är polariserande och resulterar i förlängningen i den vanliga synen att arkitekten sitter på sina höga hästar och gör en massa diagram som ingen förstår och inte har något reellt värde.

Men det finns alternativ:

Jordnära Arkitektur

Jag driver en linje som jag kallar Jordnära och Delaktig arkitektur. Det är ett koncept jag provkört i verkligheten under hösten 2018 och blir den del av Baseline 2019q3.

Fundamentet är Jordnära arkitektur. Den bygger på att man skapar en s.k. Operativ Modell som är på en, för arkitekter, förhållandevis konkret nivå beskriver företaget. Målet är att var och en i företaget skall kunna känna igen och förstå de delar som ligger nära hens verklighet och liksom kunna skapa en relation till ett eller flera hörn av modellen. Detta eller dessa hörn blir personen individuella ingång till den operativa modellen.

När man hittat en nivå så att de flesta personer i organisationen kan tycka eller tänka om sina hörn av arkitekturen kan man också föra en dialog om dessa hörn. Arkitekturen i stort är förstås svår att överblicka för de flesta men kring ett hörn kan man få feedback, tankar, förslag om förändring, problem, risker etc.

Detta skapar också en närhet mellan arkitektur och verklighet. Arkitekten pratar ett språk som verkligheten kan förstå och polariseringen mellan arkitektur och företaget i stort minskar.

Att jobba med den operativa modellen i centrum innebär inte att man undviker abstrakta modeller, men man använder dessa som ett verktyg. Som alla verktyg är dom bra om man använder dom rätt, och trasslar till det om man använder dom fel. Men det blir bara stöd och hjälp, det ersätter inte den operativa modellen.

Exempel på abstrakta modeller är olika former av landskapskartor som arkitekter brukar ta fram.

En sidoeffekt av att jobba med den operativa modellen i centrum och abstraktioner som hjälpmedel är att kan knyta samman dem i modellen med olika former av relationer. Abstraktionerna blir inte längre bara bilder med förenklingar utan snarare kontrollerade aggregat. Man skapar tydlig spårbarhet mellan olika delar av stadsplanen till faktiska delar av den operativa modellen. Vi kan nu börja prata om att kvalitetssäkra arkitekturen, och det är väl rimligt eftersom dessa abstrakta bilder ofta ligger till grund för ganska kostsamma beslut.

Jordnära arkitektur innebär alltså att man beskriver företagets verklighet på ett ganska konkret sätt (men det är fortfarande både abstrakt och arkitektur). Detta är en omöjlig uppgift utan en modell som också sköter kunskapen. Jag ser ingen möjlighet att åstadkomma detta i tex Visio.

Nackdelen med Jordnära arkitektur är att förvaltningen blir komplicerad. Verkligheten står inte still utan förändras kontinuerligt. Traditionellt försöker man lösa det genom att arkitektur är närvarande i alla projekt som skapar förändring. Eftersom arkitektur också har till uppgift att bevara det företagets strategiska inriktning kommer man snabbt att vilja inte bara vara med utan vara med från början. Man armbågar sig in tills folk är vana vid att det är lika bra att bjuda in arkitektur från början. Detta är ganska energikrävande och skapar inte bättre relationer – den som har ett projekt att driva har en budet och arkitekten skapar ofta merkostnader som, för projektet, är oväsentliga (men som har ett strategiskt värde för organisationen).

Delaktig Arkitektur

Delaktig arkitektur bygger på att man har en operativ modell enligt principen för Jordnära arkitektur och som medger att många på företaget kan knyta an till arkitekturen men spinner vidare på den tanken: Vad händer om det arkitekten ritar blir så relevant för verkligheten att verkligheten börjar använda utdrag från arkitekturmodellen när man dokumenterar och förändrar sin verklighet?

Detta är grunden till Delaktig Arkitektur. Genom att jobba nära relevanta personer i organisationen och se till att modellen är ett reellt stöd till dessa kan man också prata om att minska dokumentationen och i stället sköta den i modellen. Plötsligt kommer flera personer i organisationen att vara inne och jobba i den operativa modellen.

Detta kräver givetvis ett koncept för styrning och kontroll av förändringar, man kan inte släppa det helt fritt, ett koncept för detta baserat på Archi, git och gfitlab eller liknande med stöd för forks finns men får komma som ett fristående inlägg.

Klassiskt brukar arkitekturen ligga lite vid sidan av och man dubbeldokumenterar gränslandet – arkitekten på sitt sätt och verkligheten på sitt sätt. Principen med Delaktig Arkitektur blir att i stället att man låter diagram från arkitekturmodellen bli en del av dokumentationen av och i verkligheten.
1.4 Den Operativa Modellen Den operativa modellen beskriver som sagt verkligheten. Jag har valt att jobba med en standard som heter [Archimate}(https://archimate.com). Till skillnad mot hemmasnickrade koncept kan man köpa böcker och gå kurser i Archimate. Det är framtaget på ett universitet i Holland och förvaltas av The Open Group, främst kända för sitt arkitekturramverk TOGAF.

Vid sidan av alla floskler inom arkitektur blir Archimate ett välkommet konkret hjälpmedel för att beskriva ett företag. För att göra det praktiskt har jag gjort en del tolkningar och tagit en del beslut om hur jag vill jobba för att det skall bli tydligt.

Som vanligt måste man förstå att när en person säger ”capability” är det inte samma sak som när en annan person säger det, eller vad konceptet kan heta i tex Archimate. Sådana tolkningsbeslut måste dokumenteras lokalt, liksom vilka delar av Archimate man skall använda i normalfallet – det är ett språk och därför kan vi individuellt använda det ganska olika, precis som med Svenska eller Engelska.

Jag delar in den operativa modellen i 4 olika arkitekturdomäner som också följer det som TOGAF nämner om man lägger lite tolkning av TOGAF men linjerar inte strikt med Archimate. 1. Företaget som helhet sett utifrån. Detta finns med i TOGAF men inte som uttrycklig domän, saknas som tydligt område i Archimate även som språket (symbolerna) finns där 2. Verksamheten i företaget och den information som används 3. IT-System och digital information i företaget, heter IS-arkitektur i TOGAF men bör också delar av TOGAF domän Infrastruktur 4. IT-Teknik som används i företaget, tar resten av TOGAF Infrastruktur

Dessa bildar en naturlig kedja enligt ordningen ovan; Organisationen har strategiska mål och en funktion sett utifrån. Det kan vara tjänster man erbjuder eller för myndigheter kan det vara den beslutade styrningen från departementet. Det kan också vara ett förtydligande över åtagande som omvärlden förväntar sig så som skatteverket, naturvårdsverket med flera. Man MÅSTE inte få med allt men man KAN få med det som är intressant om man vill och det är relevant (det är genomgående i detta inlägg, det finns en verktygslåda att använda klokt). Verksamheten i företaget skall förstås leverera detta, IT-system används som hjälpmedel eller automatiserar delar av verksamheten i olika grad, IT-teknik används för att köra IT-systemen on-prem eller i molnet, men på något sätt körs de.

Relationer används för att koppla samman domänerna enligt den ordning som nämns och på ett sätt så att varje domän beror på ett VAD hos nästa medan man inom domänen beskriver HUR det går till. I vissa fall jobbar man mer konkret som ”Agda Lön körs virtualiserat på server S12” (detta är ett exempel på jordnära arkitektur).

I samtliga domäner kan man modellera VAD och i alla domäner utom ”Företaget sett utifrån” kan man också modellera HUR.

IT-System och digital information

IT-system och digital information används för att modellera det som i TOGAF kallas för IS-arkitektur och som sedan bryts upp i Applikations-arkitektur och Data-arkitektur.

Ett första exempel på IT-arkitektur (äntligen lite verkstad). Centrum för många är Applikationen eller en Applikations-modul (ex SAP-modul eller liknande). Denna har en viss funktion inom sig som beskriver HUR en applikation gör det den gör. Detta är intressant för den som bygger mjukvara men det ligger lite utanför målet för Archade, åtminstone just nu. Därför är VADet mest intressant – VAD gör Applikationen som vår verksamhet behöver och kan rationalisera bort HURet. Vi kan rita samman bild lite förenklat och utan något HUR:

För att jobba effektivt med VADet kan man dela in det i mindre delar. Här ett förenklat konkret exempel från min aktuella vardag:

Vi vill ha dokumenthantering, vilket låter enkelt, men när man öppnar den lådan ser man att det är ganska många delar som skall till. Genom att skapa en bra struktur på VADet får man en inte bara en bra och användbar arkitektur över VAD man förväntar sig i lagom portioner, man får också en utmärkt bubbla att beskriva i krav. Dessutom kan man som arkitekt vara flexibel att koppla dessa olika VAD till olika lämpliga applikationer, man kan skapa en systemdisposition över landskapet. Vi behöver A+B+C, vi kan köpa system som kan A och C medan ingen har A+B+C, det finns ett system för B men det är fristående. Vi har nu fundamentet som behövs för att skapa och utvärdera en målbild som levererar A+B+C till verksamheten.

I modellen ovan finns Digital Information. Detta är förmodligen inget begrepp man brukar använda. Språkligt använder man traditionellt Data och Information på ett konstigt sätt men jag går strikt på Riksarkivets synsätt: Information är Data man förstår. Ex: siffran 82 fristående är data och kan vara precis vad som helt men om du vet att det är ett årtal och mer specifikt någons födelseår blir det information – data man förstår. Möjligen kan man prata om Data i Databasen – där ligger bara data och det är en uppgift för applikationen att förstå data och göra information av det.

Jag har ritat IT-arkitektur kors och tvärs med denna verktygslåda under många år. Det är en stor verktygslåda med allt för många kul saker i. Jag har ständigt utvecklat konceptet och det som beskrivs här är en utveckling sedan jag sist använde det. Men den som väljer att använda Archade kommer att behöva utveckla och anpassa konceptet till den konkreta frågeställning och de konkreta behov som finns i det aktuella sammanhanget. Kanske behöver man modellera information som inte finns med i exemplen ovan.

Verksamheten i Företaget

Verksamheten följer en liknande verktygslåda där man varvar VAD med HUR; VAD gör man och HUR gör man det:

Samma symbol men annan färg för VAD som görs och HUR man gör det. Men om vi kunde ignorera HURet för våra köpta IT-system kan man inte det för den verksamhet som sker internt.

Köper man tjänster extern kan man ignorera HUR dom gör det, bara dom gör VAD vi är överens om. Det illustrerar också värdet av att skilja på VAD och HUR; man kan identifierar VAD som skall finnas i verksamheten utan att behöva lösa HUR man gör det, VEM som gör det, eller om man skall köpa det som tjänst – det tar man tag i i ett senare skede.

Det visar sig också att VADet ofta är ganska stabilt över tid medan HUR förändras när man strukturerar om processer eller förändrar organisationen. Det är också HURet man trimmar för att effektivisera VADet.

Detta VAD är det som vanligtvis också kallas för ”Capabilities” eller ”Verksamhetsförmågor”. Det finns flera stora färdiga ramverk för detta, ofta i tre nivåer och med i storleksordningen 100 till 300 förmågor på nivå två. Det visar sig att nästan alla organisationer har samma förmågor till 70-80%. En separat artikel planeras för detta.

Givetvis kan man dela upp både processer och aktiviteter i olika nivåer:

Här ser man också en indikation på hur Dynamik kan skapas; ”Delprocess 1” triggar ”Delprocess 2” vilket kan användas för att skapa ett flöde av antingen processer eller Aktiviteter. Samma gäller mellan ”Aktivitet 1” och ”Aktivitet 2”.

På lägsta nivå finns aktiviteter som skall utföras i viss ordning och det är i själva verket dessa som finns i verkligheten. Processen är bara ett sätt att styra upp hur olika aktiviteter skall kombineras.

Både processer och aktiviteter kan kopplas mot Roller och Vidare till Organisatoriska grupperingar.

Här ser vi dels hur en organisation bryts ner och att den nedersta delen har roller som är relevanta. Vi ser också en process som är relevant.

Vill man kan man beskriva vem som gör vad i processen enligt följande klassiska mönster med swimlanes:

Detta är som sagt en modell och ”Aktivitet 1” har via dessa två bilder en massa relationer. Den är en del av ”Vår Viktiga Process”, den är kopplad till ”Roll 1” som utför aktiviteten och därmed indirekt kopplad till Myndigheten och en given avdelning. Modellen håller reda på dem alla.

Alla verksamheter har en kund på något sätt och det pågår ständigt en jakt på hur man skall effektivt skall skapa värde för kunden. Ett hjälpmedel för det är Värdekedjor:

Här ser vi hur ”VAD 1” följt av ”VAD 2” följt av ”VAD 3” skapar en värdekedja som är viktig. Man kan också se hur ”Stöd-VAD 1” (namnen på sådana här exempel blir lätt obskyra) och ”Stöd-VAD 2” används av ”VAD 2” respektive ”VAD 3”. Här illustreras också hur olika IT-VAD används av verksamhets-VAD, det är i grunden ett resultat av analys via verksamhets-HUR och dess användning av IT-tjänster. Man kan också se hur ”Stöd-VAD 1” är helt automatiserat. Som redan illustrerats finns det sedan IT-system som levererar dessa IT-VAD.

Att jobba med Värdekedjor är viktigt – det är fundamentet för hur verksamhet skall fungera för att leverera värde och därmed också hur IT skall fungera för att skapa värde. Förmodligen är detta en av de viktigaste värdeskapande delarna av arkitekturen: hur skapas värde i organisationen och vad måste i så fall fungera på alla nivåer för att den kedjan skall vara effektiv.

Det som inte syns i diagrammet men som kan utläsas i en komplett modell är vilka HUR som är inblandade och att dessa HUR faktiskt måste samverka effektivt för att skapa värde effektivt. Men vissa HUR använder givetvis IT och därmed får vi även en kedja av IT-VAD som skall spela tillsammans och vidare hur faktiska IT-system måste fungera väl tillsammans för att resultat skall uppnås.

Detta illustrerar också hur arkitekturdomänen för Verksamhet kopplas samman med domänen för IT-system och digital information.

Organisationen sett utifrån

Ser man organisationen från ett utifrån-perspektiv kan man fokusera helt på dess förmågor som betyder något för omvärlden.

Detta är ett diagram som jag sällan ser hos andra och ännu inte jobbat med i ett verkligt case. Kanske är det överflödigt, men det kan också vara en bra grund för företagets strategiska utveckling. För en Myndighet blir detta en modell över VAD man beslutat att myndigheten skall göra och på frågan ”vad innebär en förändrad inriktning för myndigheten” har man en grund för en strukturerad analys av det. I värsta fall får man sådana vart 4:e år.

Här är ett rimligt exempel på vad en myndighet som MTM (Myndigheten för Tillgängliga Medier) kan tänkas ha som uppgift från departementet, förmodligen finns det betydligt mer i verkligheten:

Detta kopplar man sedan mot en värdekedja och därmed läggs hela pusslet över hur verksamhet, IT-system och IT-teknik behöver samverka för att skapa nytta:

IT-Teknik

Slutligen har vi domänen för IT-teknik. Här jobbar vi med den teknik som behövs för att köra alla IT-system. Ingången är som vanligt VAD eller Förmågor som normalt förknippas med Infrastruktur. Infrastruktur är dock lurigt och beror mycket på perspektiv; för många är e-post infrastruktur men i själva verket är det dels ett par applikationer om domänen IT-system (MS Exchange Server och MS Outlook). Det gör begreppet Infrastruktur svårt att jobba med – vems perspektiv skall man utgå ifrån.

I stället väljer man att jobba med Teknik. Vilken teknik behövs för att köra en viss applikation. Rent konkret är det här man skapar en modell över faktiska och virtuella servrar, moln-servrar, klienter, nätverk, operativsystem, databaser, lagring med mera. Som vanligt finns det ett VAD och ett HUR.

Här ser vi ett fiktivt och helt påhittat exempel på teknik för att köra den fiktiva (hoppas jag) Super-Files som nämndes tidigare. Super-files i Blått kommer från domänen för IT-system men behöver förstås en driftsmiljö i praktiken.

Här ser man hur installationen av Super-Files består av två komponenter; en MS Sql Server och en Super-Files applikations-server. Man har valt att köra dessa som separata installationer i varsin virtuell server, som delar verklig hårdvara.

Liksom tidigare innebär detta att man kopplar på information till den blå applikationen Super-Files. Tillsammans med allt som finns i denna sparsamma modell får man nu följande:

Integration – inte bara IT

Även om många anser att Integration och eventuell integrationsplattform är del av företagets infrastruktur så är det ju inte riktigt så, det är en gravt förenklad bild av informationsutbyte som i praktiken reducerar det kollegorna gör till ett IT-system eller en databas.

I grunden brukar man se Integration som ett utbyte av digital information mellan två IT-system. Vi ser numera IT-system som leverantörer av VAD och i grunden är det mellan dessa VAD som information utbyts, byter vi leverantör eller mjukvara sker utbytet även i fortsättningen även om teknikaliteterna kanske förändras:

Denna bilden haltar och man får lätt för sig att det är IT som driver integration. I stället bör man se att integration mellan IT-system finns eftersom IT-systemen används för att digitalisera verksamhet som i sig behöver utbyta information:

Detta ger en ärligare bild av VARFÖR information måste utbytas. En analys av detta behöver inte börja i IT utan kan börja i verksamheten, vilken information utbyter vi och hur kan vi förenkla det genom integration.

Givetvis är det också viktigt att se hur system samverkar på lägre nivå; här är en illustration över hur integration kan ske via en specifik integrationsmotor (många företag har flera generationers integration):

Här finns flera olika sätt att rita för att fånga det som är viktigt. I bilden ovan kan man hoppa över Integrationslösningen i mitten och skapa en relation direkt mellan applikationerna i stället, det beror på vad som är viktigt.

När väl dessa delar är inritade i modellen kan man enkelt sammanställa flöden mellan applikationer till en större karta om behovet finns.

Sammansatta modeller

Även om den praktiska nyttan med diagram som visar hela kedjan kanske sällan är så stor är det möjligt och har en god pedagogisk funktion för vad den operativa modellen som helhet innebär. Här är ett exempel:

Här kan vi indirekt se beroendet mellan vår viktiga förmåga och vår fysiska server nr 2. Den kunskapen finns i modellen (men är inte trivial att få fram maskinellt) oavsett om man gör ett diagram av det eller inte.

Detta diagram kan användas för analyser av olika slag, ex risker. Problemet är att jag valt bort massor av saker i bilden och skall man ha med processer, aktiviteter, applikationer och teknik för alla de delar som finns i vår Värdekedja blir det ett mycket stort diagram. Men samtidigt ett otroligt underlag för att göra riskanalyser över det som behövs för att leverera det som förväntas.

Att bygga upp den operativa modellen

Eftersom den operativa modellen bygger på den samlade kunskapen av alla diagram blir det praktiska arbetet ganska rättfram. Man ritar helt enkelt en del i sänder – modellen håller koll på helheten. Man inventerar domänen i fråga och ritar in den kunskap man får fatt i. Inget hindrar en att rita in information över flera domäner.

Att jobba med en logisk bit i sänder innebär också att man kan granska och utvärdera en isolerad del av verkligheten med aktörer som kan just den delen.

I en liknande aktivitet som jag genomfört hos en kund valde jag att utgå från Applikationener – det fanns en lista. För varje applikation fanns ett antal förvaltningsroller knutna och jag valde två av dem att intervjua. Resultatet dokumenterades i flera standardiserade diagram som tillsammans skapar en dokumentation över Applikationen, de tjänster den levererar, hur den används i verksamheten, vilka eventuella moduler den består av, hur dessa moduler körs i produktion.

Allt kring en applikation samlat i en ”folder” i modellen så att man kan återkomma dit och revidera om det behövs.

Det visar sig bli ett mycket praktiskt sätt att jobba och jag har inspirerat flera andra arkitekter att jobba på detta sätt, liksom jag lämnat över konceptet till organisation förvalta över tid.

Under arbetet finns det flera genvägar man kan ta för att tidigt skapa en ramverk som sedan fylls på med detaljer.

Den digitala resan - Digitalisering

Man har under en period jobbat med IT som verktyg, där verksamheten beställer IT och IT-avdelningen levererar det som beställts. Man har helt fokuserat på att IT skall anpassas och blir rätt för den verksamhet som pågår eller skall pågå. Man har haft liten respekt för vad fri kravställning och ensidig anpassning innebär; system finns inte att köpa utan måste byggas och med det kommer hela paketet med kontinuerligt utveckling och förvaltning.

I en modern digital resa kan man inte längre jobba så. Det förändras på flera plan.

Dels det uppenbar att IT inte längre är ett verktyg utan en helt integrerad del av verksamheten. Mycket liten del fungerar om inte IT-delen fungerar. Det är snarast en symbios.

Dels därför att man inte längre är intresserad av att ha egen utveckling annat än i specifika undantagsfall. I stället måste man köpa färdiga system eller komponenter som man sätter samman till system. Detta innebär att man inte heller kan kravställa fritt och jobba med ensidig anpassning (systemet skall anpassa sig), man måste jobba med ömsesidig anpassning. System och verksamhet finns i symbios och måste förändras tillsammans. Arbetet med krav kan inte ske fritt från vad marknaden kan erbjuda. Verksamheten kan önska ett stöd för sina aktiviteter men måste också anpassas dessa till det stöd som erbjuds. I praktiken innebär digitalisering att man skakar om hela HUR-bilden och skapar den på nytt, mer eller mindre lik det man hade. I grunden går det ut på att hitta en ny lösning på det VAD man vill åstadkomma.

Här blir kedjan av VAD viktigt – vilka värdekedjor finns i verksamheten och hur skall dessa digitaliseras effektivt. Dessa kopplar vidare till yttersta nivån; VAD skall organisationen åstadkomma, dvs vilket uppdrag organisationen har.