En informationsmodell i stället för flera

Vi behöver inte separata konceptuella, logiska och fysiska modeller. Vi kan kombinera perspektiven i en och samma modell och därmed få ett gemensamt språk och en gemensam förståelse tvärs över verksamhet och it.

/Peter Tallungs, IRM, 2021-03-11

Inom informationsmodellering har man vanligtvis delat in modeller efter vilken aspekt av en datadomän de beskriver. Man har tänkt sig att samma domän behöver beskrivas på olika sätt för olika intressenter. Ofta har man då skilt mellan konceptuella, logiska och fysiska modeller. Det finns andra indelningar och benämningar, men tanken är i grunden densamma.

• Konceptuell modell

En översiktlig konceptuell beskrivning på hög nivå, för att diskutera med verksamhetsfolk. Den konceptuella modellen avbildar ”verkligheten” eller rättare sagt en översikt av de företeelser som verksamheten behöver hantera. Då är inte detaljer viktiga menar man.

• Logisk modell

För att ställa krav på vilka data som behöver hanteras behöver man en logisk datamodell. Det är en modell som visar hur till exempel en databasstruktur är designad och visar all data fullständiga i alla sina detaljer. Dock innan man gjort tekniska anpassningar och prestandaoptimeringar.

• Fysisk modell

För att visa exakt hur man implementerat en databas på en specifik plattform behöver man en fysisk modell. Den visar precis hur databasen ser ut.

Tanken är (åtminstone som den ofta har framställts) att man arbetar mer eller mindre sekventiellt när man designar en databas eller någon annan datahantering. Först tar man fram den konceptuella modellen och sedan den logiska modellen som en detaljering av den konceptuella. Till sist tas den fysiska modellen fram med de avsteg man gjort för den logiska modellen av tekniska skäl. Alla tre modeller ska sedan leva vidare tillsammans. Ty alla tre perspektiven på samma datamängd behöver fortleva kontinuerligt.

Dessutom behöver man kunna spåra alla samband mellan dessa, det vill säga att man på något sätt behöver bevara alla kopplingar mellan dessa modeller. När något förändras behöver den eventuella påverkan mellan modellerna hanteras.

Problemen med separata modeller för samma domän

Synsättet ser bra ut i teorin, men jag menar att det för det första hindrar möjligheten att skapa ett gemensamt synsätt och en förståelse tvärs över it och verksamhet, och för det andra att det är ogörligt i praktiken att ha tre olika modeller för olika perspektiv på samma sak och dessutom kopplingar däremellan.

Anledningen till att vi över huvud taget skapar en modell är för att alla inblandade ska få samma gemensamma karta i huvudet, samma spelplan för att bygga vårt forskande och lärande runt. En modell ska vara vårt gemensamma språk oavsett om man är systemutvecklare eller verksamhetsexpert. När alla intressenter har olika kartor i huvudet slöar det ner all kommunikation. Kanske inte om de bara skulle röra sig om enstaka skillnader, men små skillnader på många ställen ger en kognitiv och kommunikativ friktion som kraftigt hämmar den samverkan som vi behöver.

Jag har aldrig i praktiken sett att det fungerat med att parallellt hantera och arbeta med tre olika modeller över samma domän på detta sätt. Jag vill argumentera för ett annat synsätt och ett annat sätt att lösa att vi faktiskt behöver hantera flera perspektiv samtidigt. Vi kan göra det i en och samma modell. Det går alldeles utmärkt att förena alla tre perspektiven i en och samma modell.

Jag påstår inte att alla andra typer av modeller över en verksamhet kan ersättas av en enda. Det finns perspektiv som verkligen behöver beskrivas separat. Vi kan till exempel inte trycka in en funktionskarta eller en processmodell i en informationsmodell. Men vi kan faktiskt hantera de olika perspektiven för informationsmodellering i samma modell. Jag har gjort så i många år och jag visar gärna hur, men det får bli i senare artiklar. I denna artikel ger jag en första inblick i tankesättet.

Men först, låt mig ta stöd i min argumentation från två olika håll. Det handlar om inflytelserika tankeriktningar vad gäller modellering och informationsdesign inom två delvis andra områden. De har båda varit viktiga inspirationskällor för mig.

Inspiration 1: Modellering inom programvarudesign – Domändriven design

Det finns en filosofi inom modern programvarudesign som heter ”domändriven design” (förkortat DDD), beskriven i boken Domain-Driven Design av Eric Evans. Den handlar om hur man designar den del av programkoden som representerar domänen i fråga. Det vill säga där vi har klasser som heter saker som ”Customer”, ”Product”, ”Product type”, ”Order” etcetera. Den delen av programkoden är en domänmodell, det vill säga en modell av det som verksamheten behöver hantera med hjälp av programvaran i fråga. Författaren hävdar att när man designar den delen av programkoden bör den i största möjliga utsträckning vara identisk med den mentala modell som man vill att alla inblandade, både från it och verksamhet, ska ha i huvudet. Det innebär att när man designar domänmodellen i programvaran, designar man samtidigt den mentala modell som verksamheten behöver. Det vill säga att domänmodellen i programkoden verkligen blir det gemensamma språket, tvärs över verksamhet och it. De konceptuella och logiska modellerna (vad folk i verksamheten har i huvudet) blir samma som den fysiska modellen (hur programkoden som representerar detta är strukturerad och namngiven).

Detta är i skarp kontrast till en vanlig tidigare uppfattning bland systemutvecklare där man ofta såg det som att koden gjorde man på sitt eget sätt (den fysiska modellen), sedan översatte man fram och tillbaka i användargränssnitten till hur användarna behövde se det hela (den konceptuella modellen).

Domändriven design är allmänt accepterat inom systemutveckling idag, även om tankesättet kanske inte helt och hållet har nått ut till alla systemutvecklare i sin fulla innebörd.

Boken Domain-Driven Design är även i övrigt en av mina största inspirationskällor då det gäller informationsmodellering (trots att den egentligen handlar om programvarudesign). Det är en bok jag varmt vill rekommendera till alla som arbetar med informationsmodellering. Eric Evans har en förmåga att förmedla djupa klokheter om modellering.

Det finns dock några allvarliga begränsningar med idéerna inom domändriven design:

• Domänmodellen är manifesterad i programkoden och därmed otillgänglig för andra än programmerare och egentligen bara de programmerare som arbetar med just den applikationen. Vi behöver en gestaltning av modellen som är tillgänglig för alla.
• Domänmodellen är endast uttryckt i programkod, vilket inte ger samma överblick som en grafisk beskrivning. Vi behöver en gestaltning av modellen som både ger visuell överblick och detaljerade definitioner och beskrivningar.
• Domänmodellen omfattar endast en enda applikation. Vanligen har vi i en verksamhet att göra med många samverkande applikationer, databaser, integrationer med mera. Vi behöver modeller som sträcker sig över flera samverkande applikationer.

Det är här jag menar att informationsmodellen kommer in. Vi kan låta den vara en domänmodell för hela den domän vi behöver hantera, tillgänglig för alla.

Inspiration 2: Informationsdesign – Multidimensionella grafer

Informationsdesignern Edward Tufte har betytt mycket för hur synen på hur man designar grafer och kartor för att förmedla data, information och kunskap ser ut idag. Han argumenterar, med många olika exempel, att alla riktigt intressanta grafer sammanför flera olika typer av kunskap eller information. Han kallar det för multidimensionella grafer. Tänk bara på vanliga geografiska kartor som sammanför naturgeografi (sjöar, höjdkurvor, naturtyper), politisk geografi (landskap, län, kommuner) och transportinfrastruktur (vägar, järnvägar, färjelinjer) i samma karta. Tufte har skrivit många böcker i ämnet men beskriver just detta bäst i boken Beautiful Evidence.

Hur hanterar vi då alla tre perspektiv i en och samma modell?

Okej, säger du. Så om vi översätter detta till databasdesign så behöver strukturen i databasen så mycket som möjligt stämma överens med hur vi tror att verksamheten behöver se på sakerna? Men i verkligheten har vi inte så ofta lyxen att designa en ny databas. Oftast finns det redan en databas, där saker heter som de gör och är strukturerade som de är, ofta med inkonsekvent och inte så bra namngivning och struktur. Då måste jag väl ha två olika modeller? Dels en fysisk som visar hur det ser ut i databasen samt en konceptuell som visar hur vi tror att verksamhetens personer behöver se på sakerna i verkligheten? Det vill säga att vi både skapar ett korrekt, tydligt och användbart gemensamt språk för verksamheten och samtidigt dokumenterar hur det ser ut rent fysiskt i datalagringen?

Ja, det stämmer att vi behöver beskriva och hantera de två perspektiven, fast det betyder inte att vi rent fysiskt behöver två informationsmodeller. Vi kan hantera båda perspektiven i samma modell. Det underlättar mycket om vi på detta sätt kan koppla ihop vad verksamheten faktisk hanterar med hur informationen om detta är strukturerad.

Jag går tillväga på följande sätt. Den informationsmodell jag tar fram är i grunden konceptuell. Det vill säga att den struktur jag visar och de namn jag använder är det vi kommer överens om som det mest korrekta, användbara och tydliga sättet att se på och benämna företeelserna och deras egenskaper och relationer. Så om jag hittar en tabell i en databas som heter ”Customer”, men jag inser att det inte bara finns kunder i denna utan även leverantörer, så skapar jag två entiteter för dessa. Fast jag anger också att de båda återfinns i tabellen ”Customer”. Om jag sedan hittar att någon har lagt kundens personnummer i den kolumn som heter ”PhoneNbr2” (jo det har faktiskt hänt!) så skriver jag in ett attribut i min modell som heter ”Personnummer” men anger att den ligger i kolumnen  ”PhoneNbr2”.

På så sätt blir modellen alltså i grunden konceptuell, och blir med tiden det gemensamma språket för verksamheten. Men den har också krokar ner i var och hur informationen om dessa företeelser ligger lagrade. Den blir på detta sätt en modell som verkligen kan bygga ihop de två perspektiven.

Synonymer

I verkligheten har ett och samma informationsobjekt ofta fler än två namn. Det kan heta olika saker i databasen, i programkoden, i API-er, i filer och i Data Warehouse och i rapporter. Det hanterar jag i informationsmodellen som synonymer, att en och samma egenskap heter olika saker i olika sammanhang. Det spelar mindre roll om det är av bra eller dåliga anledningar, det måste i varje fall hanteras. Då redogör jag i informationsmodellen för vilka olika synonymer som förekommer och i vilka sammanhang de förekommer. På det sättet får vi spårbarhet åt alla håll.

Informationstätheten

Det hävdas ofta att vi inte ska ha för mycket information i en och samma modell. Överblicken blir lidande. Allt flyter ihop till en enda röra. Men då kommer vi in på området grafisk gestaltning. Vi kan bli mycket mycket bättre på hur vi ritar. Vi kan få både överblick, tydlighet och detaljrikedom i samma graf om vi gör på rätt sätt. Det handlar om disposition, struktur, gråskalor, färger, linjebredder med mera. Det är ett område som är sorgligt eftersatt inom informationsmodellering. Där finns mycket att lära från andra discipliner som behöver kommunicera grafiskt, som byggnadsarkitektur, grafisk design, informationsdesign, ritteknik, kartritning. Jag planerar att visa hur i artiklar framöver.

Skillnad på modell och diagram

När vi resonerar om hur vi gestaltar modeller behöver vi skilja på ”modell” och ”diagram”. En och samma modell kan vara gestaltad i flera diagram. Jag brukar, när jag tar fram lite mer omfattande modeller, göra ett översiktsdiagram över hela modellen. Där har jag med alla ämnesområden och entiteter, men inga attribut, och bara de viktigaste relationerna. Det blir som en översiktskarta. Sedan tar jag fram flera detaljerade diagram, ett för varje ämnesområde eller sammanhållen grupp av ämnesområden. På så sätt får jag både en ”ut-zoomad” vy och en ”in-zoomad” vy på en och samma modell. I varje diagram samsas det logiska perspektivet (vad data representerar i verksamheten) med det fysiska (hur data lagras och transporteras).

Kanske är det hopblandningen av begreppen ”modell” och ”diagram” som har skapat behovet av att vilja skilja ut vad man kallar för en konceptuell modell från en logisk modell? Det vill säga att behovet av att ha olika detaljeringsgrad vid olika tillfällen har tvingat fram två separata modeller?

Men vad är då villkoret för att flera diagram ska kunna sägas vara samma modell? Jo, de måste beskriva samma domän och ha samma kontext (det vill säga sammanhang) och vara konsistenta (de vill säga inte säga emot varandra).

Vi behöver ju kunna använda alla uttrycksmedel som står oss till buds då vi modellerar. Då måste vi lämna begränsningen att en gestaltning av en modell består av endast ett diagram. Den kan bestå av flera diagram och flera olika typer av diagram, den kan bestå av diagram och text integrerat.
Mer om detta beskriver jag i artiklar framöver.

Att skapa en världsbild

På det här sättet kan vi få en och samma modell att avbilda inte bara informationen i sig utan även det som informationen handlar om, de företeelserna som informationen representerar. Vi får en och samma verklighetsbild, som omfattar både vad och hur saker hanteras i verksamheten samt hur detta representeras i informationssystemen, inklusive de diskrepanser vi tyvärr kan ha däremellan.

På så sätt riskerar vi inte att få det som vi så ofta ser i våra verksamheter, två grupper av individer med olika världsbild. En på it-sidan som ser ”verkligheten”, det vill säga hur det verkligen ser ut i databaserna. Och en annan på verksamhetsidan som också ser ”verkligheten”, och då en annan verklighet, det vill säga hur det fungerar i verksamheten utanför it.

Det är dags att vi börjar se det som en och samma verklighet. it-systemen är idag en integrerad del av verksamheten, inte som tidigare bara ett ”stöd” till verksamheten.

Modellen blir ett gemensamt språk för alla parter. Detta är i min mening det mest intressanta och kraftfulla med informationsmodellering. Som modellerare skapar du faktiskt, tillsammans med de berörda, en gemensam världsbild över allt det som behöver hanteras i en verksamhet. Det är ett stort ansvar med stora möjligheter om vi tar det ansvaret på allvar. Liksom stora missade möjligheter om vi inte gör vårt bästa, utan bara fortsätter på samma sätt som vi en gång lärt oss.

Det skulle vara intressant att få höra dina synpunkter på detta. Kommentarer är välkomna.

/Peter Tallungs, IRM