Hur får vi ordning på vår dataresurs?
Del 4: Hur kan en kanonisk modell se ut?

Om en kanonisk informationsmodell är svaret på begreppsförvirringen i våra verksamheter, hur ska då en sådan se ut för att kunna innehålla det som behövs, stödja oss i vårt arbete med framväxten av gemensamma begrepp och vara användbar för hela organisationen?

Kom de abrahamitiska religioners kanoniska skrifter till i grupparbeten? Så bör i varje fall vår verksamhets kanonisk informationsmodell skapas.

/Peter Tallungs, IRM, 2024-04-25

Kraven på en kanonisk informationsmodell

De tre föregående artiklarna har mynnat ut i att en kanonisk informationsmodell är svaret på den stora förvirring av begrepp och termer vi har i våra verksamheter, inte minst i it-miljön men egentligen överallt. Den senaste artikeln sammanfattade de krav vi behöver ställa på en sådan modells omfattning, innehåll, uttryckskraft och användbarhet.

Men det svaret blir ingången till en ny frågeställning: Hur ska då en sådan modell se ut rent praktiskt för att svara upp mot behoven? I denna artikel vill jag ge min bild av detta. Jag har under de senaste åren skrivit artiklar om informationsmodellering som var och en och på olika sätt ger delar av svaret. Eller i varje fall mina erfarenheter efter att ha studerat och praktiserat detta i många olika verksamheter. Därmed blir svaren här till stor del i form av referenser till tidigare artiklar.

Trots att det blir ett återbruk, ett hopkok av tidigare texter, hoppas jag att den här sammanställningen kan vara av värde för de som står i begrepp att skapa en kanonisk modell.

I det följande listar jag alla de krav som framkom i den föregående artikeln Hur får vi ordning på vår dataresurs? Del 3: Vi behöver en kanonisk modell, och försöker besvara vart och ett med bland annat referenser till olika tidigare artiklar.

Krav på modellens omfattning

Krav 1:  Modellen ska omfatta verksamhetsdomänen, alla de företeelser som verksamheten hanterar, samt deras egenskaper och regler

Det betyder att modellen i grunden inte ska avbilda en fysisk datastruktur som vi råkar ha, utan begrepp som beskriver de företeelser som verksamheten hanterar, och som vi därför har data till för att representera. Det är samma som att säga att modellen ska vara konceptuell.

Man kan tro att en konceptuell informationsmodell uttrycker informations- eller datastrukturer men egentligen uttrycker den i grunden det som information och data representerar, nämligen allt det som en verksamhet behöver hålla reda på eller kommunicera om. Det vill säga allt det vi behöver data om. Vilket omfattar i stort sett alla begrepp i verksamheten.

Traditionellt har man inte inkluderat verksamhetsregler i en informationsmodell, utan man har sett det som att informationsmodellen ska uttrycka endast det man normalt får av en databasstruktur.

Men min erfarenhet är att informationsmodellen är det mest lämpliga stället för verksamhetsreglerna. Ty en verksamhetsregel rör alltid en viss entitet, ett visst attribut, en grupp av attribut eller i varje fall ett ämnesområde.

På det sättet blir en informationsmodell för en verksamhet eller verksamhetsfunktion en beskrivning av alla verksamhetsobjekt, alla verksamhetsbegrepp, alla data som representerar dessa och alla verksamhetsregler. Ja hela den operativa verksamhetslogiken faktiskt.

Så det är kanske mer korrekt att kalla det för en domänmodell. Jag börjar luta åt det. En verksamhetsdomän är just det område, den värld av samlade företeelser, som en verksamhet eller verksamhetsfunktion behöver hålla reda på, inklusive hur vi vill benämna och hantera dessa.

Läs vidare:

Om hur vi kan se och använda informationsmodellen som en domänmodell:
Informationsmodellen som domänmodell

Om hur verksamhetsregler har sin plats i informationsmodellen:
Informationsmodellering: Om verksamhetsregler

Krav 2:  Modellen ska definiera samtliga begrepp samt beskrivningar i övrigt

Det betyder att modellen behöver ha definitioner av alla begrepp i sammanhanget. Både för entiteter, attribut (även för de attribut som innebär relationer till andra entiteter) och uppräknade värden (så som statuskoder med mera).

Observera att man inom begreppsanalys och terminologiarbete skiljer på begrepp och term. Det är viktigt att vi gör det, så vi inte rör ihop diskussion om betydelser med diskussion om benämningar. Det är annars ett vanligt hinder för ett bra terminologiarbete. Begrepp är det som en företeelse är, det som en definition pekar på. En term är ett namn vi kan använda för företeelsen.

Redan här ser vi att modellen inte kan vara ett diagram allena utan även behöver ha text. Och texten bör vi se som en integrerad del av modellen.

Det är annars vanligt att man sätter likhetstecken mellan modell och diagram. Vilket inte räcker för modeller som ska fånga begrepp och termer. Och för övrigt inte mycket annat heller som vi behöver kunna ha våra modeller till.

Krav 3:  Modellen ska normera termerna

För varje företeelse behöver vi ange en term som ska vara normerande. Det vill säga det som vi bestämmer är det mest korrekta namnet för företeelsen, det som vi förordar från och med nu ska användas i alla sammanhang, både i databaser, filer, tjänster, användargränssnitt, modeller, verksamhetsregler, beskrivningar med mera. Undantag är vardagliga sammanhang där man kan förväntas förstå vad som avses.

Om man har två språk i verksamheten så behöver man skriva både definitioner och termer, liksom övriga beskrivningar, i båda språken.

Förkortningar bör undvikas. Om vi börjar förkorta måste vi normera även förkortningar.

Läs vidare:

Om begrepp och termer i informationsmodellen:

Det viktigaste du gör som informationsarkitekt: Arbetet med verksamhetens begrepp och språk

Sjutton missuppfattningar om arbetet med verksamhetens begrepp

Om text i informationsmodellen:

Försvar för enkla verktyg – del 3: Skrivverktyg

Informationsmodellering: Integrera text och grafik

Bilden visar ett utsnitt ur en informationsmodells textdel som visar hur vi definierat begrepp och normerat termer för både ett attribut: ”Ärendestatus – Offertförfrågan” och attributets värdeförråd: ”INK”, ”Inkommet” med flera värden.

Krav 4:  Modellen ska beskriva datastrukturerna i olika databaser, filer och tjänster

Vi behöver även dokumentera det fysiska perspektivet, det vill säga hur data för företeelserna är strukturerat i databaser och filer.

Krav 5:  Modellen ska beskriva synonymer

Vi behöver lista alla synonymer som förekommer. Samma företeelse har ofta många olika namn i olika databaser, filer och användargränssnitt.

Krav på modellens perspektiv

Krav 6:  Modellen ska beskriva både det konceptuella perspektivet och det eller de olika fysiska perspektiven i samma vy

Detta följer av krav 1–5 ovan. Traditionellt har man sett en konceptuell modell och en fysisk modell som helt olika modeller, men jag menar att det är en stor fördel att ha både de konceptuella och fysiska perspektiven i samma modell. Det är inte konstigt att ha två vyer i samma modell, så länge vi använder grafikens möjligheter att tydligt skilja dessa åt. Då får vi en tydlig och direkt koppling. Vi behöver inte länka ihop två olika modeller, en som visa hur vi vill se på saker och ting och en annan hur den data som representerar sakerna faktiskt ligger lagrade.

En modell är till för att vi ska få en gemensam bild. Det är svårt om verksamheten har en bild och it en annan.

Bilden visar ett utsnitt av en entitet i ett ER-diagram. Modellen är i grunden konceptuell men i ett grått typsnitt finns uppgifter om det fysiska perspektivet, det vill säga i detta fall vilken tabell och kolumner data lagras som representerar företeelsen och dess egenskaper.
Vi ser att grunduppgifter om en organisation vid en punkt i tiden lagras i tabellen ”FORETAG”, och värden för dess olika egenskaper lagras i kolumnerna: ”PRIMARYKEY”, ”UPDATED” och så vidare. Vi ser även källorna för informationen: Arbetsförmedlingen, Bisnode, Bolagsverket, Statistiska Centralbyrån och Skatteverket.

Läs vidare:

Om hur man kan inkludera den fysiska strukturen i en konceptuell modell:

En informationsmodell i stället för flera

Krav på modellen som arbetsplattform

Krav 7:  Modellen ska beskriva sin versionshistorik

Det är viktigt att man i modellen kan se hur den har utvecklats över tiden. Vad som har tillkommit eller ändrats, av vem och varför. Det är inte något som tillgodoses av en automatisk versionshantering i ett versionshanteringssystem. Ty det handlar det inte om varje liten ändring, som till exempel rättning av en felstavning, utan om väsentliga ändringar som vi är intresserade av att spåra. Och informationen behöver finnas i själva modelldokumentet och inte på annat ställe.

Bilden visar ett utsnitt från textdelen av en del av en informationsmodell. Delen avser ett specifikt ämnesområde: ”Clearing Transactions”. Vi ser revisionshistoriken för det ämnesområdet. När en ändring gjorts, vad som ändrats och vem som ändrats. Varje version är också sparad så man kan backa. Det är viktigt att versionshistoriken är tydlig så man vet varför något har ändrats och man vet vad det innebär att gå tillbaka till en tidigare version.

Krav 8:  Modellen ska ha notiser

Vi ska kunna skriva daterade och signerade notiser utspritt på aktuella platser i modellen. På så sätt kan modellen bli mer än ett snapshot av kunskapsläget just nu. Den blir till en plattform för det gemensamma lärandet.

Observera att notiserna behöver ha permanent plats i texten, men tydligt skilja sig från modellinnehållet i sig.

Bilden visar ett utsnitt från textdelen av en informationsmodell, med insprängda notiser i avvikande färg och typsnitt, för att separera dessa från modellinnehållet som sådant. Med daterade och signerade notiser, inlagda på de ställen i modellen som de avser, kan vi följa och kommunicera runt arbetet.
På det sättet blir modellen mer än en modell, det blir en arbetsplattform för det gemensamma lärandet som modellering alltid är. Tillsammans med revisionshistoriken gör det också att vi kan senare kan gå tillbaka och se vad som hänt och varför. Ofta, kanske flera år efteråt, behöver man förstå vad som hände och varför, för att kunna göra en ny bedömning baserad på tidigare arbete.

Läs vidare:

Om hur vi kan inkludera innehåll i vår modell som gör den till en plattform för gemensamt lärande, vill jag återigen hänvisa till samma artikel som ovan:

Försvar för enkla verktyg – del 3: Skrivverktyg

Krav på modellens uttryckskraft

Krav 9:  Modellen ska ha största möjliga uttryckskraft

För att kunna uttrycka allt vi behöver uttrycka behöver vi frihet i hur vi kan använda och kombinera grafik och text. Vi behöver gråskalor, färger, typsnitt, linjetyper, struktur, disposition med mera.

Läs vidare:

Om hur vi kan bli bättre på den grafiska gestaltningen av våra modeller:

Försvar för enkla verktyg – del 2: Ritverktyg

Vi kan göra bättre modeller – Om gestaltning med grafik och text

10 tips för bättre gestaltning av en informationsmodell

Informationsmodellering: Om ämnesområden

Informationsmodellering: Om struktur i flera nivåer

Om hur vi kan utöka vår repertoar av diagramtyper för våra informationsmodeller:

Modellera livscykler med tillståndsdiagram

Modellera strukturer med instansdiagram

Arbetet med modellen

Vi har nu gått igenom hur en informationsmodell kan utformas för att fungera som en kanonisk informationsmodell för en verksamhet. Vad den behöver kunna uttrycka och hur den ska kunna uttrycka det. Men det räcker ju inte för att modellen verkligen ska fungera och göra nytta. Det handlar lika mycket om hur vi kan arbeta med modellen, involvera de vi behöver ha med, exponera och marknadsföra modellen. Sätta modellen i arbete.

Modellen är ett viktigt tanke- och kommunikationsverktyg, men det räcker inte med ett riktigt bra verktyg, slipat och intrimmat för ändamålet. Det krävs bra hantverkare också, och bra arbetssätt.

Men det är en annan historia, om arkitektarbetet. Hur vi blir riktigt bra arkitekter. En arkitekt är ju en som tar fram modeller och, det viktiga, använder modellerna för att stödja individer, team och verksamheter i det de behöver göra. En verktygslåda som fungerar är dock en förutsättning.