Modellens syfte – Är det viktigt?

Det sägs ofta att man ska tänka på syftet när man tar fram en modell. I denna artikel vill jag ifrågasätta det påståendet.

/Peter Tallungs, IRM, 2025-12-04

Behöver varje modell ha sitt eget syfte?

Vad menar man egentligen när man säger att det är viktigt att tänka på vilket syfte en modell ska ha när man tar fram den? Ska man anpassa modellen för en specifik målgrupp, ett visst tillfälle och vad man just då vill visa? Betyder det att vi ska ha olika modeller, var och en med sitt särskilda perspektiv och sin tänkta användning?

Visst, allt man gör har ju ett syfte på något sätt. Men jag vill ändå argumentera mot tanken att modeller måste vara specialanpassade. De modeller vi baserar vårt arbete på som informations- och verksamhetsarkitekter är mångsyftande och behöver kunna används brett över tid. Då blir det missvisande att prata om ett avgränsat syfte.

För att utveckla en verksamhet över tid behöver vi en gemensam bild som rymmer flera perspektiv. Modellen fungerar som en plattform för gemensam undersökning, gemensam förståelse och som ett gemensamt språk. Inte minst behöver verksamhet och it, två delar som ofta hanteras alltför separat, samlas runt modeller som visar båda perspektiven i samma vy. Ty egentligen är verksamhet och it som två kommunicerande kärl. Vi kan inte förstå det ena utan att förstå det andra. Vi kan heller inte utveckla det ena utan att samtidigt utveckla det andra.

Först när vi gör det kan vi på allvar betrakta och hantera it som en fullt integrerad del av verksamheten.

Vi tar visserligen ibland fram modeller med ett tillfälligt syfte, en skiss på en whiteboard för att testa en idé till exempel. Men de modeller som är själva fundamentet i våra arbeten som arkitekter behöver kunna tjäna flera syften samtidigt, i olika sammanhang över tid.

Men då ska vi inte se dem som mångfunktionella i stil med en schweizisk fickkniv, alltså en samling enklare verktyg hopklämda i samma skal. Snarare handlar det om en kombination av perspektiv som stödjer, förstärker och kontrasterar varandra. På så sätt kan vi jämföra olika aspekter och faktiskt samlas runt en mer komplett helhet.

Låt mig ge två exempel på modeller vi arbetar med och hur de kombinerar och integrerar olika dimensioner, målgrupper, syften och användningar.

1. Verksamhetskartan

En verksamhetskarta är en karta som visar hur en verksamhet är uppbyggd, med alla dess delar (funktioner) och hur de samverkar (via tjänster, både digitala och analoga) med varandra och med omgivningen. I samma vy visas vilka it-stöd (it-applikationer) och mänskliga roller som finns i dessa funktioner. Samt informationsflöden mellan alla dessa delar, inte bara mellan applikationer utan i samma vy mellan funktioner, roller och tjänster, interna såväl som externa.

En sådan karta är baserad på ett systemteoretiskt synsätt på hur organisationer egentligen fungerar och ser verksamheten som ett ekosystem, ett fraktalt nätverk av samverkande autonoma funktioner.

Kartan ger både överblick och detaljer och kan användas både för att analysera, dokumentera och förmedla kunskap om hur verksamheten är uppbyggd, det vill säga hela organisationens inre och yttre ekosystem. Den kan till exempel användas för följande:

• Skapa en heatmap över verksamhetens olika delar, som funktioner, it-applikationer, tjänster, roller och informationsflöden, utifrån till exempel: kostnad, kritikalitet, förändringsbehov, status med mera.
• Analysera och hantera beroenden mellan funktioner, it-applikationer och utvecklingsinitiativ.
• Följa datalogistiken (data lineage) samtidigt genom både verksamhet och it, från var en datamängd skapas, via var den hanteras, transformeras och kombineras, till alla ställen där den slutligen används.
• Tjäna som kontextkarta, där man anger, förankrar och avgränsar var andra modeller gäller. Till exempel kan en viss informationsmodell gälla för en viss verksamhetsfunktion, it-applikation eller tjänst (intern eller extern).

2. Rika informationsmodeller

På IRM har vi byggt vidare på det halvsekelgamla konceptet med informationsmodeller till något mer kraftfullt som sammanför flera typer av kunskap i samma modell. Något jag vill kalla för rika informationsmodeller. (Den traditionella typen av informationsmodeller vill jag se som ”anorektiska”, i det att de visar så lite av vad som är möjligt och önskvärt.)

En rik informationsmodell beskriver både de företeelser som finns i domänen och hur dessa representeras som data. Den visar egenskaper, relationer och regler, och hur dessa representeras i våra it-system, databaser eller filer. I praktiken går det inte att skilja arbetet med att definiera och beskriva datastrukturer från arbetet med att beskriva det som datastrukturerna representerar Därför behöver vi hantera och beskriva båda dimensionerna i samma modell.

Den rika informationsmodellen väver ihop olika perspektiv genom att kombinera text och grafik.
Vi använder ER-diagram kompletterat med tillstånds- och förekomstdiagram när det behövs.

Samtidigt dokumenterar vi hur man kommit fram till det modellen visar. Det gör modellen till mer än en ögonblicksbild av ett resultat. Den blir en arbetsplattform för att över tid, steg för steg, bygga, vidareutveckla och, när så behövs, revidera den gemensamma förståelsen. Modellen visar inte bara vad vi kommit fram till utan även hur vi tog oss dit, vilka antaganden vi gjort, hur långt vi kommit, vad vi bygger resultatet på och vilka utestående osäkerheter vi ännu har.

En sådan modell kan användas för många olika syften. Här är några exempel:

• Beskriva verksamhetens domän, det vill säga alla de företeelser verksamheten eller verksamhetsfunktionen är intresserad av, med definitioner av begrepp.
• Beskriva den operativa verksamhetslogiken i form av verksamhetsregler.
• Dokumentera verksamhetens de-facto-språk, det vill säga vilka (mer eller mindre korrekta) benämningar som används i olika sammanhang.
• Skapa ett gemensamt väldefinierat språk som hela organisationen kan enas kring.
• Beskriva eller designa de datastrukturer som används för att hantera data som representerar verksamhetens företeelser i olika it-system, filer med mera.
• Förklara hur, när och varför vi har kommit fram till saker eller fattat vissa beslut om information, benämningar och verksamhetsregler.
• Fungera som en struktur för att samla och hantera frågeställningar som dyker upp under arbetets gång.
• Ge en grund för att säkerhetsklassa information.
• Ge en grund för att organisera datastyrning och datahantering.

Låt oss inte begränsa oss

Exemplen ovan är att se som breda kategorier. De kan brytas ner i mer konkreta och specifika användningar. En och samma modell tjänar både syftet att fungera som en plattform för att analysera verksamheten och att beskriva den, det vill säga hjälpa oss att skapa en gemensam förståelse samtidigt som vi dokumenterar hur saker faktiskt hänger ihop.

Därför menar jag att det skulle vara direkt fel att i förväg bestämma ett enda syfte för en sådan modell. När vi tar fram en modell ska vi inte tänka att den bara ska användas till en sak. Tvärtom behöver vi hela tiden se hur vi kan bygga vidare – fler användningsområden, fler saker som kan visas tillsammans, fler möjligheter att samlas runt samma bild och skapa förståelse. Och samtidigt minska den kommunikativa friktionen tvärs över gränserna i organisationen.

Vad hindrar oss?

En anledning att man tidigare har begränsat sig vad gäller syfte kan vara att man ha trott att det behövts för att hålla isär aspekter och inte röra till det. Det är ofta så modellering lärs ut. Men jag godtar inte det argumentet. Visst, det kanske kan vara ett pedagogiskt grepp i en utlärningssituation, men det leder lätt fel. Det motverkar ju det vi egentligen vill uppnå, att människor med olika bakgrund och tillhörighet ska kunna samlas runt samma bild och börja tala samma språk.

Det är sant att vi behöver hålla isär aspekter. Men det kan vi göra i en och samma modell, om vi bara använder grafikens möjligheter på ett genomtänkt sätt. Det är just det som är styrkan, att i samma vy kunna växla sömlöst mellan olika dimensioner, se samband och jämföra. Det är då vi får den djupare förståelsen tvärs över olika delar av verksamheten.

Anledningen till att man betonat vikten av ett avgränsat syfte kan också vara att de modelleringsverktyg man använder inte räcker till. De tillåter inte att vi ritar och skriver på det sätt vi skulle behöva för att bygga levande, användbara modeller. Men det är ju rätt bakvänt om det är verktygen som sätter gränserna för hur vi jobbar. Då blir vi mer operatörer av dåliga verktyg än hantverkare som väljer, anpassar och när det behövs, själva utvecklar rätt verktyg för jobbet.

Vi borde titta mer på andra yrkesområden. Ta till exempel Edward Tufte, den välkände experten på statistik och grafisk kommunikation. Han menar, och visar med många exempel, att riktigt bra grafer är multidimensionella, det vill säga de som kombinerar många olika typer av information i samma bild.

Det gäller våra modeller också. De som kan kombinerar flera aspekter och användningar är de som verkligen är värdefulla. Vissa användningar tänkte man på redan från början, andra dyker upp som trevliga överraskningar senare.