Informationsmodellen som domänmodell

En informationsmodell beskriver inte bara data i en verksamhet utan även det som data representerar. Det vill säga allt det som verksamheten behöver hålla koll på, med andra ord verksamhetens domän.

Varje gång jag säger att informationsmodellen beskriver information så skorrar det lite falskt i mig. För jag tycker inte att det är helt rätt beskrivet, eller i varje fall inte speciellt klargörande.
Ja faktiskt till och med missledande, på sätt och vis. För då utelämnar vi det viktigaste. Låt mig förklara.

Det är sant att en informationsmodell beskriver strukturen hos informationen i något sammanhang. (Eller ofta snarare hur den bör vara.) Det kan vara data i en databas, i en fil, i en applikation eller en tjänst. Men det kan också vara den konceptuella strukturen av den information som delas av en verksamhet eller en verksamhetsfunktion.

Så långt är allt väl. Lätt att förstå och prata om. Men sedan kommer det som komplicerar, men som också gör det hela mer intressant. Mycket mer intressant i min mening.

Data i sig representerar i sin tur något som finns där ute i verkligheten. Varje entitet i en informationsmodell representerar en klass av företeelser som verksamheten behöver hålla reda på förekomster av. Det kan vara kunder, produkter, produkttyper, ordrar med mera.

Den dubbla rollen

Alltså, informationsmodellen avbildar både strukturen hos data i sig och utgör samtidigt en modell av domänen det vill säga de företeelser som verksamheten behöver hantera.

Informationsmodellen är följaktligen lika mycket en domänmodell som en modell över informationen som behövs för att hantera domänen.

En domänmodell beskriver verksamhetens ”värld”, de företeelser som behöver hanteras av verksamheten, beskrivna och benämnda på ett sätt som passar verksamhetens sammanhang och syfte. Den vill uttrycka den gemensamma förståelsen av det som hanteras och utgöra det gemensamma språket. Det är svårt att överdriva betydelsen för en organisation av att utveckla och vårda den förståelsen och det språket.

Det här är något som sällan kommer upp på bordet, men som jag menar är väsentligt för att förstå vad vi egentligen håller på med när vi modellerar.

Informationsmodellens största potential

Det är just där, som domänmodell, informationsmodellens största potential ligger menar jag, och samtidigt den hittills mest underutvecklade. Vi har, om vi blir skickliga i vårt värv, en förmåga att beskriva, hantera och utveckla hela verksamhetslogiken på ett sätt som annars inte är möjligt.

Jag har sett hur informationsmodellen enkelt och naturligt kan fylla en central och viktig roll i en verksamhet. En informationsmodell kan bli en gemensam karta över det som verksamheten hanterar, en domänmodell. Den kan bli bäraren av de gemensamma begrepp och det gemensamma språk som vi behöver. Jag har till och med sett att den kan bli bäraren av hela den grundläggande verksamhetslogiken. Och inte bara det, den kan även bli plattformen för utforskandet och utvecklandet av verksamhetslogiken och språket. Och det med överraskande enkla medel.

Informationsmodellering kan därmed fylla en mycket mer central roll i analys och utveckling av en verksamhet och dess informationssystem än den gör idag. Inte bara vad gäller analys och utveckling. Vi har ju i alla sammanhang behov av att arbeta för en gemensam förståelse, krispiga begrepp och ett gemensamt språk.

Fast i så fall behöver vi tänka om och tänka nytt. Vi behöver öppna upp beskrivningstekniken till en helt annan kraftfullhet. En huvudtanke med denna artikelserie är att föreslå hur vi kan få till detta.

Vad säger ”information” egentligen?

Nu till något helt annat. Ett annat sätt som namnet ”informationsmodell” skorrar lite falskt för mig har med förledet ”information” att göra. Ett måhända mindre problem, men ändå irriterande.

Om jag säger till min granne att jag jobbar med informationen på ett företag så skulle hon anta att jag är informatör eller skribent av något slag. Och kanske skulle jag sedan försöka förtydliga genom att fortsätta med att jag arbetar med en modell över informationen. Då skulle hon nog, om hon inte ryckte på axlarna och gav upp, göra sig en bild av att jag på något sätt ser över hur företaget ska informera externa eller interna intressenter. Eller kanske ser hon framför sig hur jag tar fram en modell för omvärldsbevakning. Så låt oss vara överens om att ”information” inte är en tillräckligt specifik benämning på det vi modellerar.

I själva verket beskriver en informationsmodell inte strukturen på information i största allmänhet utan endast strukturen och meningen hos den information som behöver listas i en verksamhet. Det vill säga den data som beskriver klasser av företeelser som har förekomster av något slag. Förekomster av saker som verksamheten behöver hantera och därmed behöver lista på något sätt. Till exempel kunder, ordrar, produkter, anställda, postnummer och tusen andra saker.

Och egentligen aldrig det som man i första hand tänker på som företagets information som företagets historia, affärsplan, årsredovisning, ägarförhållande, affärsidé, verksamhetsbeskrivning, kundvärde, marknad, kreditvärdighet med mera.

Kanske det skulle vara tydligare att prata om ”datamodell” som amerikanarna gör?

Så vad blir mitt förslag på namn på de modeller vi gör? Tja, traditionen gör väl att vi får fortsätta att säga ”informationsmodell”, fast det inte är speciellt förklarande och måhända tar emot lite grand. Och vi kan väl tillstå att ”datamodell” är en synonym. Och vara medvetna om att vi i själva verket modellerar en domän i sig utöver informationen och språket om domänen. Även om vi kanske ännu inte är mogna för att kalla det för domänmodell?

Vad tycker du? Kan du se informationsmodellens roll som domänmodell?  

/Peter Tallungs, IRM

Prenumerera på artikelserien om informationsarkitektur

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 25 februari. Det handlar då om skillnaden mellan data och data.  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

11 Kommentarer
  1. Lars Taxén
    Lars Taxén says:

    Här är några personliga reflektioner. Jag tycker det är helt rätt att kalla modellen för en domänmodell, men att den bara är en dimension (rumslig – en gemensam karta som du skriver) av en fullständig beskrivning av en domän. Andra dimensioner är tidsbaserad (process), normbasread (regelsystem), och gränsbaserad (övergång till andra domäner). Alla dessa måste ses som en helhet där de olika dimensionerna samverkar. Modellen ska ses som ett medel för att samordna och koordinera verksamheten och inte som en avbildning av ”verkligheten”.

    Sedan tror jag att vi måste också tänka om när det gäller ”information”. Vi kan kalla modellen ”gemensam”, men i grunden så tolkar varje person som betraktar modellen den olika (vi har olika hjärnor helt enkelt). Information måste ses som något personligt; det som varje person konstruerar i sin hjärna med hjälp av modellen, och som gör det möjligt att agera i en speciell situation.

  2. Daniel Bjarsch
    Daniel Bjarsch says:

    Det här är en spännande frågeställning. Jag möter i mina uppdrag som arkitekt ofta på olika tolkning av just begreppet domänmodell. Personligen försöker jag -om möjligt- reservera det begreppet för informationsmodeller som tagits fram ur ett verksamhetsperspektiv i syfte att beskriva och förstå hur olika koncept och företeelser inom verksamhetsområdet hänger ihop och hanteras.
    De mer tekniska varianterna av informationsmodeller (hur koncepten och företeelserna hanteras i olika systemlösningar) vill jag hellre kalla något annat, tex datamodeller eller liknande. Men det är inte alltid jag lyckas 🙂 …och det viktiga är väl att vi som producerar modellerna och de som konsumerar dem är överens om vad det är vi tittar på och hur det kan användas.
    Men min fasta övertygelse är det finns inget starkare verktyg när systemlösningar ska utvecklas än just en väl genomarbetad domänmodell. Som jag ser det beskriver den då precis de viktigaste aspekterna av vad systemlösningen egentligen ska hantera, och hur.

  3. Peter Tallungs
    Peter Tallungs says:

    Svar till Lars Taxén
    Tack för dina alltid lika intressanta kommentarer.

    Om vad av en domän som en informationsmodell kan beskriva:
    Du skriver att en informationsmodell endast beskriver den rumsliga dimensionen av en domän.
    Och det kan kanske stämma, så länge vi pratar om traditionella informationsmodeller. Fast jag är inte säker på vad du menar med rumslig, och var man drar gränsen för detta.

    Men jag har i många år strävat med att fånga mycket mer informationsmodeller, så att de kan bli mer av en fullödig domänmodell. Jag menar att informationsmodellen, utökad på rätt sätt, ger den bästa strukturen för detta.
    Av de dimensioner du räknar upp så skulle jag vilja säga följande:
    – Den normbaserade dimensionen: Om du menar normer i det mjuka sociala (aktörsorienterade) systemet en verksamhet är så håller jag med om att det inte kan fångas i informationsmodellens struktur. Det vill säga regler som ”Vi strävar efter en jämn könsfördelning i företaget”. Men däremot menar jag att informationsmodellen ger en bra struktur för alla regler som gäller det som inom systemteorin kan ses som det ”hårda systemet” eller ”aktivitetsorienterade systemet”, Exempel: ”En kund som inte handlat på två år byter status till ”Tidigare kund””. Den regeln hör nämligen hemma i beskrivningen av orsaker till de händelser som ändrar status hos kund. Ty alla begrepp och regler som har med kundstatus att göra hör ju hemma hos beskrivning av kund menar jag.

    – Den gränsbaserade dimensionen: Jag har ofta i informationsmodeller över en verksamhet beskrivit hur man ska översätta olika saker mellan olika domäner. Tex när man importerar data från en extern källa eller då man rapporterar till myndigheter på ett fastställt format. Det måste väl vara att beskriva en gräns?

    – Tidsbaserad dimension. Här kan jag hålla med dig. Processer är svåra att täcka in i strukturen hos en informationsmodell. Men om vi talar mer allmänt om det dynamiska beteendet hos de företeelser som beskrivs i informationsmodellen så brukar jag kunna täcka in det. Till exempel tillståndsdiagram för att beskriva reglerna för dynamiken. Och instansdiagram för att beskriva skeenden som är svåra att beskriva på andra sätt.

    Om vad en modell beskriver:
    Du har förstås rätt att en modell aldrig beskriver verkligheten. Den försöker beskriva det som vi behöver resonera om och hantera, på det sätt som passar vårt syfte och sammanhang. Det gäller för övrigt alla beskrivningar, överallt och alltid.

    Om huruvida en modell kan vara gemensam för flera människor:
    Du har rätt i att vi aldrig kan ha precis samma uppfattning om något. (Hur skulle vi förresten kunna verifiera det?) Men vi kan väl enas om att vi kan komma till en i praktiken tillräckligt gemensam förståelse för att samverkan ska bli möjlig. Jag ser det som en axel med grader av gemensam förståelse, där vi i ena änden har en total brist på kommunikation (”god dag yxskaft-änden”) och vi i andra änden har fullständigt samförstånd. Den änden är naturligtvis ett helt imaginärt gränsvärde. Jag är ju inte ens helt och hållet överens med mig själv från stund till stund!
    Men vi kan etablera en tillräckligt gemensam förståelse inbegripande begreppsvärld och språk för att vi ska kunna samverka och bygga kunskap. Vi vill heller inte ha total förståelse. Ty det är viktigt att vi kan bryta olika synsätt mot varandra. Men vi vill ha tillräcklig samsyn, så att vi kan förstå varandras argument. Det är detta jag menar att vi kan kalla för att modellen uttrycker vår gemensamma förståelse (just nu).

    Vad tror du om det Lars?

  4. Peter Tallungs
    Peter Tallungs says:

    Svar till Daniel Bjarsch.
    Jag håller med dig helt och hållet.

    För att vara lite tydligare behöver vi nog skilja på å ena sidan modelleringstekniken/ beskrivningstekniken/verktyget ”Informationsmodell” och å andra sidan vad vi använder den till, det vill säga vad vi producerar.

    – Jag kan beskriva en verksamhet eller del av verksamhet. Det blir då en domänmodell.

    – Jag kan beskriva data/information i ett visst sammanhang. Det blir då en data- eller informationsmodell. (Anledningen till att jag nu inte skiljer på data och information är att jag inte riktigt håller med om den gängse distinktionen mellan dessa. Mer om det i en senare artikel.)

    – Jag kan beskriva begreppen i ett sammanhang, tex. i en bok. Det blir då en begreppsmodell.

    Sedan är det svårt att inte göra en data-/informationsmodell utan att på något sätt ändå, åtminstone indirekt, beskriva både domän och begrepp. Liksom det är svårt att göra en data-/informationsmodell eller en domänmodell utan att på något sätt ändå, åtminstone indirekt, definiera begrepp.

  5. Petter
    Petter says:

    Ja du Peter. Det är ju lite av skomakarbarn du beskriver. Alltså att vi som är så nördiga på begrepp och ”statiska” strukturer är så dåliga på att sätta bra termer på våra egna viktigaste betraktelseobjekt. Vi accepterar inte när verksamheterna vi modellerar slirar på orden och deras betydelse. Men på vår hemmaplan där kan vi rycka på axlarna och säga ”jag kallar mig informationsarkitekt” och ”jag jobbar med information” det är inte så noga så länge jag själv fattar vad det betyder.

    Själv brukar jag bara kalla mig verksamhetsutvecklare. För det är åtminstone syftet med vad jag gör på dagarna.

  6. Peter Tallungs
    Peter Tallungs says:

    Kommentar till Petter:
    Jo, jag brukar kalla mig för informationsarkitekt, fast då har jag ganska mycket själv dragit upp gränserna för vad det är och vad det inte är. Jag tror att vi som jobbar med detta är ganska överens om vad någon slags kärna i området är, men sedan varierar det nog vilt var vi drar gränsen till andra områden. Fast det är nog likadant inom många områden. Som Service Design, Enterprise Architecture, Enterprise Design, Verksamhetsarkitektur, Affärsarkitektur, Lösningsarkitektur och så vidare. Å andra sidan skulle det vara synd att låsa fast betydelserna helt och hållet. Ett område måste ju få utvecklas, och då blir det olika skolor som betonar olika saker.

  7. Lars Taxén
    Lars Taxén says:

    Peter, jag tror du är något mycket viktigt på spåren när du funderar över den ”dubbla rollen” för informationsmodellen, och det är insikten att beskrivning av verksamhetens ”värld” är det grundläggande i all slags modellering. Det tycker jag är tydligt i din beskrivning av vad som ingår i ditt perspektiv på informationsmodellen som en domänmodell. Frågan är hur vi ska hantera den insikten.

    Som jag ser det måste domänmodellen utöver en traditionell informationsmodell i form av t.ex. en Entity/Relation- modell, också omfatta de andra dimensionerna jag nämnde: en tidsbaserad (process), normbasread (regelsystem, t.ex. hur man benämner och reviderar entiteter – tänk dokumentnummer och versioner), och gränsbaserad (övergång till andra domäner). Utöver dessa så måste man också modellera det objekt verksamheten bearbetar. Och, som sagt, alla dessa måste ses som en helhet där de olika dimensionerna samverkar. Det går helt enkelt inte att definiera en verksamhet utan att ha med alla dessa aspekter.

    Sen är frågan hur en sådan domänmodell ska se ut. Alla har vi olika erfarenheter och insikter som formar hur vi tänker, och ingen modell är mer ”rätt” eller ”sann”. Det är mer en fråga om hur effektiv en modell är får att uppnå det man vill. Om det funkar för dig att tänka på en informationsmodell som en domänmodell så är det förstås helt OK.

    Men min övertygelse är att vi måste ifrågasätta själva grunden för hur vi tänker om modellering för att vi ska komma vidare. Jag tror t.ex. att det är ineffektivt att hantera alla dimensionerna ovan i samma modell. Det försvårar uppkomsten av den gemensam förståelse för vad verksamheten är. En bättre metodik att ha en modell per dimension utan att för glömma bort att de är ömsesidigt beroende av varandra.

    En annan fråga är det där med ”gemensamt”. Visst har du rätt i att i praktiken så handlar det om att etablera en tillräcklig förståelse för att vi ska kunna samverka. Man behöver inte bekymra sig om vad vi egentligen menar med ”gemensam”, det funkar ändå. Men om vi vill i grund och botten förändra hur vi arbetar, måste vi vara mer precisa när det gäller de mest grundläggande företeelserna vi rör oss med. Om vi litet slarvig pratar om ”gemensamma” saker när det i själva verket inte finns något sådant, så kommer våra modeller att bli missvisande och otillräckliga.

    Det gäller också begreppet ”information”. Det är förledande lätt att tänka på information som något som en sak; något man kan hantera som ett paket – lagra, transportera, ta fram osv. Men i grunden är det feltänkt. Textsträngen ”CAA 105 2360” är bara tecken på ett papper; obegriplig för de flesta. Men för en Ericsson-anställd betyder den en programvaruenhet. Så även här måste vi tänka om.

    Ett sådant omtänkande görs förstås inte över en natt; det kommer att ta decennier. Men någonstans och någon gång måste vi börja.
    Lars

  8. Peter Tallungs
    Peter Tallungs says:

    Svar till Lars Taxén.
    Jag tror vi är överens om allt det väsentliga. Men kanske vi lägger olika betydelse i ordet ”modell”.
    Jag menar att när vi pratar om en modell om något, av en domän (System of Interest) så vi måste skilja på följande.

    1) Den modell som den är i mitt eller våra huvuden . Det vill säga min eller vår gemensamma uppfattning. En * mental modell * om så vill. (Vi får just nu bortse från frågan om till vilken grad vi verkligen har samma uppfattning, och hur vi kan veta det).

    2) *Modellens gestaltning* Kan vara ett diagram, en text, diagram och text, flera diagram av samma sort, eller en kombination flera olika slags diagram och texter. Eller egentligen vilka kombinationer av media som helst, som gör jobbet att på bästa sätt förmedla den mentala modellen. (Jag jobbar med en kombination av olika diagram och strukturerad text för att på bästa sätt gestalta en mental modell.)
    Fördelen med att skilja på dessa två saker som båda kan kallas för ”modell” i vårt vardagsspråk blir att vi kan tala om och jobba med att utveckla gestaltningen av våra modeller oberoende av frågan om den mentala modellen, den som ju ska ska representeras av gestaltningen är bra eller dålig i sig (Dvs användbar till sina syften).
    Det som gör två (eller flera) olika diagram, kanske av olika diagramtyper till kompletterande gestaltningar av *samma modell* är följande:
    – Beskriver samma domän (samma ”system of interest”)
    – Beskriver samma eller överlappande (en eller flera) ”aktivitetssystem” i systemteoretisk mening.
    – Konsistens, dvs att de inte säger emot varandra
    – Samma kontext (och syfte, om man tolkar ordet brett) , tex beskriver ”Vad vi (vi som varit inblandade) just nu uppfattar som vår gemensamma uppfattning om vilka företeelser vår verksamhet behöver hålla reda på, inklusive begrepp, regler och dynamisk beteende hos dessa, samt hur det representeras i data i datalagring och meddelande. Plus hur detta översätts vid kommunikation med omvärlden.”

    Detta kräver enligt mig en kombination av olika typer av diagram och texter, men är enligt mig ändå samma modell, eftersom det är något helt och konsistent enligt ovan.

    Sedan har jag inte ambitioner att kunna täcka alla aspekter av en verksamhet eller en verksamhets domän (vilka det nu är?, det finns ju oändligt många aspekter). Men jag tycker att vi i de sammanhang jag jobbat kunnat få fram modeller som täcker betydligt mer och på bättre sätt än vad som brukar vara fallet. Detta genom att överge många traditionella sanningar inom vårt område som ”en informationsmodell är ett ER-diagram”, ” en modell ska täcka endast en aspekt”, ”en modell ska inte innehålla för mycket för då blir den oöverskådlig”. I stället har vi inspirerats av andra designdiscipliner där man på ett helt annat sätt kombinerar olika slags kunskap i en och samma modeller.

    Vad tror du om det Lars?

    Vad gäller diskussion om ”data” och ”information” vill jag passa frågeställningen några veckor, eftersom jag tagit upp frågan i en artikel som publiceras först då.

  9. Niklas Wahlby
    Niklas Wahlby says:

    Hej! Försöker själv att göra distinktionen mellan användningen av informationsmodeller genom att kalla en typ av informationsmodell som ”Begrepps-informationsmodell” eller ”Behovs-informationsmodell” (förk. BIM) för att understryka att det finns ett behov från verksamheten att använda en viss mängd information. BIM visualiserar hur informationen håller ihop med syfte att skapa en gemensam kommunikation och förståelse för den information verksamheten använder. Det kan därmed också finnas flera BIM uppdelade efter verksamhet.

    En annan typ av informationsmodell ser jag är den som handlar om hur vi ska strukturera information för att kunna förse verksamheten med den information som de använder – alltså en modell som ligger till grund för struktur och kravställning av information, inte kommunikation och förståelse kring information. Låt oss kalla denna modell för Data-informationsmodell (DIM). Denna DIM ligger till grund för hur information lagras och struktureras och kan ses som den med ”klassiska” modellen med informationsområden/subject areas/domäner såsom avtal, produkt, kund, roll etc. i syfte att på ett effektivt sätt kunna sätta ihop information som verksamheten kravställer att de vill kunna konsumera (har behov av)..

  10. Peter Tallungs
    Peter Tallungs says:

    Svar till Niklas Wahlby.
    Det låter som att du gör två modeller av samma domän, med olika syften.
    Om jag tolkar dig rätt så är den första det som brukar kallas Konceptuell modell eller kanske Begreppsmodell. Den andra är en så kallad fysisk modell (eller kanske logisk modell?).
    Senare i artikelserien kommer jag att beskriva hur man kan samla båda perspektiven (eller om man vill se det som tre perspektiv) i samma modell.

  11. Lars Taxén
    Lars Taxén says:

    Svar till Peter

    Det vi nog är överens om är att det behövs mer än en ER-modell för att beskriva en verksamhet. Det du säger under punkt 2 verkar väl helt rimligt tycker jag.

    När det gäller synen på modeller så menar jag att uttrycket ”mental modell” är feltänkt. Eftersom vi inte kan titta in i vårt eget eller andras huvuden, kan vi aldrig veta om det finns en modell där eller hur den i så fall ser ut. Vi måste utgå från att det enda påtagliga; att det finns en modell (modellens gestaltning) alla kan se, peka på, komma med synpunkter på osv. Alla som ser modellen gör sina egna, unika tolkningar av den. Ingen uppfattar den likadant eftersom vi är unika biologiska personer. Det som är gemensamt är modellens gestaltning, aldrig det vi har innanför pannbenet.

    Det här gör att det allt överskuggande problemet blir hur modellerna ska vara utformade så att de som arbetar i projektet tittar åt samma håll – att deras individuella uppfattningar om vad vi håller på med inte skiljer sig alltför mycket åt. Modellerna måste vara anpassade till våra biologiska förutsättningar helt enkelt. Den här aspekten tycker jag är gravt underskattad när man utformar modeller (tänk TOGAF – i princip oanvändbart).

    Tyvärr är det som det ju brukar vara – att de vanliga begreppen vi rör oss med (information, kunskap, modell, system, osv.) efterhand blir så inrotade att vi inte ifrågasätter dom. Det är när verkligheten slår tillbaka (tänk skolplattformen i Stockholm) som vi måste ifrågasätta dom, gå till grunden och se dom i nytt ljus.

    Bara mina tankar …

Lämna en kommentar

Want to join the discussion?
Dela med dig av dina synpunkter!

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *