Hur får vi ordning på vår dataresurs?
Del 3: Vi behöver en kanonisk modell

Vi behöver en informationsmodell som fungerar som ett gemensamt språk och knyter ihop alla olika strukturer och namn som förekommer i vår verksamhet. Vad kan vi ställa för krav på en sådan?

/Peter Tallungs, IRM, 2024-04-11

Behovet av en kanonisk informationsmodell

De två föregående artiklarna, Om röran i struktur, begrepp och namn och Hantering av struktur begrepp och namn, handlade om att vi behöver skapa ordning och reda på begreppen och termerna för dataelementen i vår verksamhet, och att det är orealistiskt att överallt i en lite större verksamhet önska sig en helt enhetlig struktur och namnsättning. Det vi i stället kan göra är att skapa en modell som fungerar som ett gemensamt språk och knyter ihop alla olika strukturer och namn som förekommer i olika sammanhang.

Ibland kallas en sådan modell för en kanonisk informationsmodell. Kanonisk betyder ungefär erkänd, det vill säga att modellen är erkänd i hela verksamheten.

Men hur ska en sådan modell vara utformad för att verkligen fungera och förmedla det som behöver förmedlas? För att avgöra det behöver vi först resonera om vilka krav vi ska ställa på en sådan modell. Denna modell har ju en mycket central roll i en verksamhet, vilket ger oss som ska leda arbetet med att ta fram, förvalta, utveckla och förmedla en sådan modell ett stort ansvar. Här kommer ett försök att formulera dessa krav.

Vad ska en kanonisk informationsmodell omfatta?

En kanonisk informationsmodell bör omfatta:

1. Verksamhetsdomänen

Allt det som verksamheten hanterar, både företeelserna i sig samt deras egenskaper och regler.

2. Begrepp

Klara tydliga definitioner, samt ofta även beskrivningar i övrigt.

3. Normerande termer

De termer vi kommer överens om för att benämna varje företeelse vi beskriver, både företeelserna i sig, dess egenskaper, och möjliga egenskapsvärden då det gäller referensdata.

Med normerande menas att det är de benämningar som vi anser vara mest korrekta och ska styra språkbruket i sammanhang där man behöver vara tydlig. Som i namnsättning av datatermer, samt i verksamhetsregler, rapporter med mera.

4. Datastrukturer

De strukturer som används i olika system och filer för att lagra och hantera de data som representerar företeelserna i verksamhetsdomänen.

5. Synonymer till termerna

De som förekommer i olika system och filer.

Två perspektiv i en och samma modell

Omfattningen av den modell vi tänker oss (punkt 1–5 ovan) kan delas in i två delar.

Punkt 1, 2 och 3 (verksamhetsdomänen, begrepp och normerande termer) motsvarar det som kallas för en konceptuell informationsmodell. Det vanliga är att den konceptuella modell man tar fram endast är skissartad. Det finns en uppfattning att när man rör sig på den konceptuella nivån behöver man inte vara så precis. Jag menar att det är ett misstag. Vi behöver en detaljerad och precis modell över företeelserna som verksamheten hanterar för att bli en fast grund för oss att stå på.

Punkt 4 och 5 (datastrukturer och förekommande termer) motsvarar det som kallas en fysisk informationsmodell eller datamodell.

Skillnaden mellan en konceptuell modell och en fysisk modell är att en konceptuell modell beskriver verksamhetens perspektiv på företeelserna som hanteras, och en fysisk modell beskriver de datastrukturer som används för att representera samma företeelser.

Traditionellt har man de konceptuella och fysiska perspektiven åtskilda i olika modeller, som olika dokument. Jag menar att vi i stället bör se på det som att det inte är två helt olika modeller utan två olika perspektiv på samma saker, vilka kan och bör samsas i samma modell.

Men först till en underliggande fråga. Hur kommer det sig att de två perspektiven kan vara olika? Varför kan inte de fysiska och de konceptuella perspektiven överensstämma? Det kan finnas två skäl till olikheter. Det första skälet är tekniskt, det vill säga att det ibland kan vara fallet att de strukturer vi har i våra it-system för att representera företeelserna i verksamheten behöver vara annorlunda strukturerade än den bild vi vill förmedla av företeelser i sig själva. Fast ofta är det behovet överdrivet menar jag. Idag har vi mycket bättre möjligheter att ha strukturer och namn i våra system som överensstämmer med hur vi tänker oss företeelserna i verksamheten. Ett par decennier tillbaka behövde vi förkorta alla namn på dataelement och ta hänsyn till prestanda på ett sätt som vi inte behöver längre.

Det andra skälet är praktiskt. Ofta har verksamheter flera olika it-system som vuxit fram under olika tider och sammanhang och att det därför finns skillnader. Skillnaderna beror då egentligen inte på tekniska orsaker utan historiska. Då är det svårt att komma ifrån att vi på samma gång behöver två olika perspektiv (eller flera ändå). Men det att vi behöver två eller flera perspektiv betyder inte automatiskt att vi behöver två (eller flera) modeller. Vi kan mycket väl hantera två (eller flera) olika perspektiv i en och samma modell. Jag har tillämpat det i många sammanhang och det finns bara fördelar med det angreppssättet menar jag, stora fördelar.

Ty det finns ett starkt skäl till att hålla ihop de konceptuella och fysiska perspektiven så mycket det bara går. Vi behöver en gemensam karta och vi behöver en gemensam förståelse. Varje liten skillnad ökar friktionen i kommunikationen i verksamheten, i synnerhet mellan it och verksamhet. Den friktionen ökar kraftigt om vi behöver mappa mellan detaljer i olika modeller i stället för att de olika perspektiven kan överblickas i samma modell.

Inom modernt tänkande runt modeller (det som inom programmering kallas domändriven design, se den tidigare artikeln Informationsmodelleringens strategi) är också hållningen att de konceptuella och fysiska perspektiven bör överensstämma så mycket det bara går för att minska friktionen i samarbetet mellan verksamhet och it. Vilket förstås inte är möjligt om vi pratar om befintliga it-system, eller standardsystem, som har sina strukturer och namngivning vilka sällan överensstämmer med vad vi kommer fram till med vår kanoniska modell.

Det går utmärkt att sammanföra båda perspektiven, det vill säga att modellen i grunden är konceptuell men att fysiska termer och strukturer refereras i samma modell. På så sätt blir modellen mycket mer effektiv som tanke- och kommunikationsverktyg. Vi kan direkt se hur företeelserna och begreppen i vår verksamhet mappar mot dataelement, och var dessa återfinns i systemlandskapet. Men det är viktigt att de två perspektiven skiljs åt grafiskt och tydligt i modellen.

Mer än ett snapshot

Det vanliga är att en modell endast visar vad vi kommit fram till, det vill säga ett snapshot av ett kunskapsläge i tiden. Det är en stor tillgång om modellen också visar vad som har hänt och händer med modellen, när och varför vi valt att modellera på ett visst sätt, vad vi valt bort, utestående osäkerheter med mera. Modellen visar då inte bara ett färdigt, eller tillfälligt, resultat utan förvandlas till en arbetsyta, en plattform, för det kontinuerliga gemensamma lärandet.

Ofta händer det att man jobbar med ett område av modellen, gör om det kraftigt för att prova ett alternativt synsätt, men att man sedan går tillbaka till det ursprungliga synsättet. Senare kommer frågeställningen åter. Då vill jag återvända till det alternativa synsättet, se vad som hände förra gången, och varför, och kanske göra samma resa en gång till. Då är de viktigt att jag kan se varför vi egentligen gav upp det alternativa synsättet förra gången.

Det vi behöver för att modellen ska bli en arbetsplattform för det gemensamma lärandet är två saker:

1. Versionshistorik

Vi behöver en versionshistorik, en logg över vad som är gjort och av vem. Versionshistoriken behövs per ämnesområde i modellen.

2. Notiser

Vi behöver notiser utspridda i modellen, integrerade med de egentliga modellelementen. Notiser om det pågående arbetet, daterade och signerade.

Versionshistorik och notiser utgör integrerade modellmetadata och är något som kan lyfta hela utvecklingsarbetet. Efter att jag introducerat detta sätt att jobba för ett projekt sa projektmedlemmarna till mig:

”Vad skönt. Förut när vi i ett möte fick upp olika saker som vi behövde utreda så saknade vi en struktur för att följa och hantera dessa. Det blev ett sammelsurium av olika mötesanteckningar. Nu kan vi anteckna varje sådan punkt som en notering i informationsmodellen. För en fråga rör alltid någon specifik del av modellen, kanske en entitet, en egenskap eller ibland ett ämnesområde. Då kan jag på varje ställe i modellen få en överblick över hur dialogen har gått fram. För ofta är det ju flera turer rörande samma element i modellen.”

Det viktiga är att både versionshistoriken och notiserna finns på modellen, där det de avser finns, och inte separat i något annat verktyg.

Maximal uttryckskraft

Modellen ska ha största möjliga uttryckskraft, det vill säga att vi ska kunna uttrycka allt det vi behöver uttrycka, och gestalta det så tydligt som möjligt. Avsikten med en modell är att den ska vara ett kommunikationsverktyg men inte bara det utan mer ett tankeverktyg, en plattform för vårt gemensamma lärande. Därmed är det viktigt hur vi gestaltar modellen. Vi behöver både grafik och text, vi behöver kunna använda grafikens alla möjligheter, som olika typer av diagram, strukturer, former, linjer, gråskalor, typsnitt, färger. Och vi behöver integrera text och grafik. Du kan läsa mer om detta i den tidigare artikeln 10 tips för bättre gestaltning av en informationsmodell.

En informationsmodell är en karta, det vill säga att den har en geografi om man gör rätt. Upp och ner samt höger vänster betyder något. Vi kan se vad som finns nära varandra och vad som finns långt ifrån.

En bra karta integrerar många typer av information i samma vy. Det är först då man ser olika typer av information i samma grafik som en graf blir riktigt intressant. Därför behöver vi bli skickliga i att använda grafikens möjligheter till en rikare gestaltning.

Vi kan lära av andra yrken där man beskriver och kommunicerar med hjälp av grafik, som byggnadsarkitekter, stadsplanerare, ingenjörer, tekniker. Där finns en rikedom av kunskap och erfarenheter.

Modellens dubbla syfte

En modell ska både fungera att modellera i och att bara tillägna sig, det vill säga studera. Det viktiga är att det är samma vy både när man modellerar och när man läser modellen. Att modellera är ett i högsta grad interaktivt arbete. Jag studerar modellen, tänker och ändrar om vart annat i en snabb cykel. Vi vill inte modellera i en typ av användargränssnitt för att sedan behöva ta ut en rapport för att se resultatet på ett annat sätt.

Låt mig göra en liknelse. På åttiotalet i ordbehandlingens barndom såg ett dokument helt annorlunda ut när man skrev det mot när man skrev ut det. Datorerna hade inte grafiskt användargränssnitt och kunde inte på skärmen presentera de typsnitt och skiljetecken man hade valt, utan man fick skriva ut dokumentet för att se hur det blev. Det var en stor begränsning och när det kom nya datorer med grafiska gränssnitt började man tala om värdet av WYSIWYG (What You See Is What You Get). Att det är viktigt då man jobbar i ett dokument att kunna se resultatet precis som det blir. Så behöver också våra modelleringsverktyg vara. Det är ännu viktigare än då vi skriver texter.

Modelleringsverktyg som inte begränsar oss

Jag och mina kollegor förespråkar enkla verktyg, som Microsoft Visio för att rita och Microsoft Word för att skriva. Då är vi inte inlåsta på de sätt man är i ett mer begränsande verktyg utan kan använda hela den uttryckskraft vi behöver för att modellerna ska bli meningsfulla.

Den friheten och flexibiliteten har hjälpt oss att utveckla våra modellers uttryckskraft och roll i de organisationer vi jobbat i. Från de enkla traditionella EA-diagrammen till de rikare modeller som har en betydligt bredare och viktigare roll tvärs över it och verksamhet.

Vi som forskar och utbildar inom området har ett ansvar att lyfta kunskapen om vad en modell är och kan vara. För att utveckla ett stelnat kunskapsområde behöver man ”go back to basic” och förutsättningslöst börja om, utan de föregivna hinder vi har skapat oss. Det är det vi har gjort och fortsätter göra, tillsammans med kollegor i landets verksamheter.

Men i roller hos kundorganisationer är vi ofta hänvisade till de verktyg som våra organisationer har bestämt. Det är i högsta grad begränsande. Det är frustrerande när vi inte kan göra det som vi vet behöver göras.

Alla kan inte följa de råd vi ger. Verktygen dessa organisationer har valt begränsar dem. Vi ser det hos våra kunder och vi ser det hos eleverna på våra kurser. De säger ofta att de förstår vad de skulle behöva göra för att göra en bra modell, men det går inte i de verktyg de har. Men vi fortsätter ändå att missionera om hur ett modelleringsarbete behöver se ut för att bli den kraft som behövs i verksamheten. Det kan ju fungera som ett riktmärke, så vi vet vad vi i varje fall försöker närma oss i de begränsande verktyg som man är hänvisade till.

Ty det värsta är om informationsarkitekter ser sig själva som operatörer av verktyg, att uppgiften är att bara göra det som verktygen styr dem till. I stället för att göra det som verkligen behövs, och välja de verktyg som stödjer det. Det blir annars som att anlita en snickare som är en överdängare på spikpistol och excellerar i spikande. Men som envisas med det verktyget också där det inte är ändamålsenligt. Och kanske inte ens ser allt annat som behöver göras. Det som du kan uttrycka med ditt verktyg blir din värld. Det du inte kan uttrycka ser du inte. Mer om detta kan du läsa i tidigare fem artiklar på temat Försvar för enkla verktyg:

Försvar för enkla verktyg del 1 .

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

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

Försvar för enkla verktyg del 4 – Modellbibliotek,

Försvar för enkla verktyg del 5 – Publicerings-och-samarbetsverktyg

Är dessa de krav vi kan ställa? Kom gärna med dina synpunkter. Hur kan då en kanonisk informationsmodell se ut för att tillgodose dessa krav? Det får bli nästa artikel!