Informationsarkitekturens mörka materia; all den information som inte finns i databaser

En stor mängd av den information som hanteras i en organisation finns inte strukturerad i tabeller, databaser eller liknande. Oftast är det frågan om text men kan också vara bild, ljud, video eller kombinationer av format. Det vill säga allt sådant som brukar kallas ”ostrukturerad” information. Hur kan vi identifiera och hantera detta? 

Informationsarkitekturens mörka materia

Om vi på allvar vill stödja informationshanteringen i en verksamhet så måste vi börja intressera oss för all den så kallade ”ostrukturerade” information som finns i organisationen. Den är en mycket stor mängd av den totala informationsmängden, men hittills har inte många intresserat sig för detta. Det är på så sätt att likna vid en mörk materia för oss. Den finns där och den är viktig, men vi vet inte mycket om den och vi låtsas att den inte finns. 

Det vi kallar ”ostrukturerad” information är egentligen inte alls ostrukturerad

För att kunna hantera något så behöver vi först identifiera vad det är vi ska hantera. Vilka enheter pratar vi om? Ett fruktbart sätt att se på informationen i en organisation är att se den som olika dokument. Ett dokument i denna mening är en artefakt som bär information av något slag, och som vi väljer att se som en sammanhållen enhet. Det är naturligt att varje organisation har mycket information i form av sådana enheter av information. Avtal, polices, produktblad, villkorstexter, ritningar, modeller, powerpointpresentationer, bilder, böcker, videoinspelningar, blogginlägg, bilder, reklam- och informationsmaterial, scheman, utbildningsmaterial, broschyrer, specifikationer, offerter, fakturor, rapporter, prognoser, epostmeddelanden, med flera. Jag väljer här att kalla alla dessa saker för dokument.

Det viktiga är att ett sådant dokument omfattar det man vill se och hantera det som en helhet, det vill säga att varje del av innehållet i dokumentet får en mening av det sammanhang som dokumentet utgör. Ett dokument är alltså inte en godtycklig paketering av data eller information. Lika lite som en roman bara är ett antal ord, eller en bild endast ett antal pixlar. Helheten är mer än summan av delarna. Detta är mycket viktigt, och något som ofta förbises av alla oss som är vana vid de uppstyckade data som finns i databaser.

Ofta har man kallat den information som finns i dokument av olika slag för ostrukturerade data för att skilja den från det som finns i databaser, som man då menar är strukturerad. Jag hävdar att detta är fel. Data eller information i ett dokument är nästan alltid extremt strukturerad. Du kan ju inte skaka om innehållet så att alla bokstäver, meningar, stycken blandas utan att dess mening går förlorad.

Informationen i dokument är alltså också strukturerad, fast på ett helt annat sätt än informationen i en databas.

Men informationen i en databas kan faktisk också ses som dokument. Där finns kundposter, avtal, offerter, produkter. Varje sådan post är vanligen mer än en post i en tabell. En faktura till exempel är mer än den databaspost som representerar fakturahuvudet, den inkluderar även fakturaradernas databasposter. Dokument är således att se som en betydelsebärande helhet av information, oavsett hur det lagras.

Man kan dock tänka sig alternativa beteckningar. Ibland kallar man detta för informationsobjekt, de enheter av information som man kan betrakta som meningsfulla enheter. Jag använder här termen ”dokument” för att jag tycker att den är mer konkret. När man hanterar innehåll på webbplatser kallas innehållet för ”content”, och kanske kan man då kalla dessa enheter av information man hanterar för content objects (innehållsobjekt)?

I vilket fall som helst, vad vi än kallar det för, det jag väljer att kalla för dokument, är det viktiga objekten för all informationshantering i våra verksamheter.

Vem hanterar dokument?

Förr fanns alla dokument i fysisk form på papper. Numera lagras och distribueras det mesta digitalt. Men fortfarande har dock försäkringsbolag och myndigheter kvar hyllkilometrar av papper, vilka är arkiverade i bergtunnlar. Men övergången till digital hantering betyder inte att dokumenthantering har försvunnit. Tvärtom! Mängden av dokument har bara ökat och behovet av hantering är minst lika stor som förut. Skillnaden är bara att de flesta nya dokument är digitalt lagrade.

Det finns yrkesgrupper som traditionellt har administrerat denna flod av dokument. Det finns bibliotekarier och det finns arkivarier. Dessa har alltid funnits. Sedan har det tillkommit de som arbetar med innehållet på stora webbplatser. Det de gör brukar kallas för Information Architecture då det handlar om strukturen, och Content Management då det handlar om själva innehållet. Några av dessa har intresserat sig för det bakomliggande, det vill säga inte bara det innehåll som finns på en viss webbplats utan för mer eller mindre allt material som innehåller information i en verksamhet. Det brukar då ibland benämnas Enterprise Information Management eller Enterprise Content Management.

Var kommer vi informationsarkitekter in?

Vi som tillhör den stam av informationsarkitekter som ursprungligen kommer från databasdesign och datamodellering har i ringa utsträckning brytt oss om dokumenthantering. De som också kallar sig för informationsarkitekter men som kommer från, och ingår i, skaran av UX:are (User Experience- specialister) har mest intresserat sig för strukturen på en webbsida eller liknande. Men som sagt; vissa av dessa har börjat intressera sig för en verksamhets hela dokumentflora och kallar då området för Enterprise Information Management. Fast de kallar det ofta inte för dokument utan det mer neutrala ”content”.

Men jag tycker att det är dags att ändra på detta. Låt oss se informationsarkitekturområdet i hela dess bredd, att vi intresserar oss för de strukturer som behövs för att hantera all slags information i en verksamhet, oberoende av struktur eller media.

Det är därför jag skriver denna artikel om hur vi kan hantera dokument.

Olika perspektiv på dokumenthanteringen

Om man studerar området dokumenthantering så ser man snart att det finns olika perspektiv. Olika yrkesgrupper har haft olika roller vad beträffar hanteringen av dokument och har därmed utvecklat sin egen apparat av begrepp och praxis.

Jag tror att de vanligaste perspektiven är följande:

  • Informationsanvändning och användbarhet
    Hur blir de strukturer av innehåll vi bygger i olika sammanhang, till exempel på webbplatser, användbara för de som behöver informationen.
  • Informationssökning
    Hur kan användare hitta och komma åt de dokument de behöver (index, söksystem, taggar, klassificering).
  • Dokumenthantering
    Hur kan vi hantera dokumenten under hela deras livscykel (versioner, varianter, mallar).
  • Systemperspektiv
    Vilka applikationer hantera dokumenten och hur är hanteringen integrerad (HR-system, ekonomisystem, workflow-system, dedikerade informationslager, arkivsystem, Content Management-system, med flera). Här fokuserar man på hur dokumenten flödar genom hela it-miljön.
  • Förmågeperspektiv
    Hur de olika dokumentflödena går mellan olika parter, interna och externa.
  • Processperspektiv
    Hur en viss process hanterar de dokument som den är beroende av eller producerar.
  • Organisation av kunskap
    Hur kan vi hantera dokument med tanke på organisation av den kunskap som de bär.
  • Informationssäkerhet
    Hur kan vi klassa dokument för krav på tillgänglighet, riktighet och konfidentialitet och hur kan vi se till att hantera de kraven (säkerhetsklassning av information).

Men var kommer då vi informationsarkitekter in? Informationsarkitektur handlar ju om att göra modeller och beskrivningar, och att använda dessa för att stödja olika aspekter av informationshanteringen. Jag menar att vi informationsarkitekter behöver stödja alla dessa perspektiv. Det vi bidrar med är att skapa modeller och beskrivningar för de strukturer som behövs för att hantera dokument och att använda dessa modeller och beskrivningar för att guida hela organisationen med detta.

Stödförmågor för hantering av dokument

Varje organisation behöver generella förmågor eller funktioner för att hantera dokument och informationsobjekt av olika slag. De är stödförmågor eftersom de är till stöd för andra förmågor. De tillhandahåller generella verktyg och funktioner.

Denna typ av verksamhetsförmågor brukar ofta ses som tekniska förmågor eftersom varje funktion ofta kräver en viss typ av it-stöd. Men jag menar att det är fel. Som alltid handlar förmågor om mycket mer än teknik, ty varje förmåga kräver förutom it-stöd även processer, rutiner, regler, kompetens, strategi, ledning med mera. En förmåga är alltid en egen liten specialiserad verksamhet med allt vad det innebär. Tekniken som behövs är en integrerad del av en förmåga.

Dessa förmågor är att betrakta som stödförmågor eftersom ingen av dessa är någon central förmåga hos en verksamhet, det vill säga det som är specifikt för en verksamhet. En stödförmåga är stöd till en eller vanligen flera av de centrala förmågorna. Man kan säga att stödförmågorna för dokumenthantering tillsammans utgör den infrastruktur som behövs för hantering av dokument och andra sammanhållna informationsobjekt. Även termen infrastruktur kopplas ofta ihop med teknik men det är förstås i detta fall mycket mera. Infrastruktur är helt enkelt den struktur som ligger under de andra i arkitekturen, det vill säga som de andra är beroende av.

Vilka är då alla dessa stödförmågor för hantering av dokument som vi som informationsarkitekter ska stödja? Här följer en genomgång av de förmågor, varje verksamhet behöver i någon form, som har med hantering av dokument att göra.

  • Stöd för samarbete
    Handlar om att utbyta information i form av meddelanden som alla kan ses som dokument av olika slag. De kan delas in i följande stödförmågor:
    • Stöd för kommunikation, intern och extern
      E-post, text- och röstmeddelanden med mera.
    • Stöd för möteshantering
      Mötesbokning, rumsbokning, videomöten med mera.
    • Stöd för hantering av sociala nätverk och delande av kunskap
      Bloggar, wikis, samarbetsytor, diskussionsforum etcetera.
  • Stöd för sökning och åtkomst till dokument
    Processande av sökfrågor, hantering av sökresultat, sökanalys och rapportering, hantering av sökindex.
  • Stöd för kunskaps- och informationshantering
    • Stöd för skapande av informationsobjekt
      Dokumentscanning, OCR-scanning, stöd för dokumentskapande, versionshantering, hantering av formulär med mera.
    • Dokumenthantering
      Dokumenthanteringssystem, ytor för olika team, nätverksdrives etcetera.
    • Organisering av dokument
      Kataloger, klassificering av dokument, taggning och indexering av dokument.
    • Informationssäkerhet
      Säkerhetsklassificering, autentisering, kryptering, rättighetshantering.
    • Livscykelhantering
      Arkivhantering, fysisk och digital dokumentförstöring etcetera.
  • Stöd för hantering av semantik
    • Stöd för vokabulärer
      Ordlistor, ämnesscheman, klassificeringsscheman, nyckelordlistor etcetera.
    • Stöd för representation och översättning av information
      Resurser för tolkning och översättning, mallar, scheman etcetera.
    • Hantering av dokumentmetadata
      Metadatamodeller, metadatalager. Metadata är av central betydelse för dokumenthanteringen. Därför handlar resten av artikeln om detta.

Alla verksamheter oavsett storlek behöver i princip dessa förmågor, men de är ofta i mindre organisationer så enkla att man typiskt inte tänker på att de finns. Men de finns egentligen alltid där, i någon form. Ofta är de rudimentära och outvecklade. Kanske det räcker, men i många fall behöver vi stärka dessa.

Dokumentmetadata

Hur behöver vi informationsarkitekter stödja dessa förmågor? En central aspekt är att ta fram en gemensam modell för dokumentmetadata. För att ha någon typ av ordning i floden av dokument behöver vi på något sätt tagga dessa med egenskaper. Detta för att kunna sortera, söka, strukturera och på andra sätt hantera dokumenten. Men då måste vi bestämma och definiera egenskaperna i fråga. Det kallas ofta för dokumentmetadata. Metadata definieras ”data som beskriver data”, i detta fall, data som beskriver dokument. Det handlar ju om data om dokumentet i fråga, till skillnad mot det data som finns i dokumentet.

Vi kan dela in dokumentmetadata i två kategorier. Generella metadata (Core Metadata) och Utökade metadata (Extended Metadata).
Generell dokumentmetadata är metadata som stödjer informationshantering tvärs över hela organisationen och som därmed måste finnas för alla dokument oavsett typ. Utökad dokumentmetadata är den metadata som varierar beroende på typ av dokument. Ofta beror det på de speciella behov en viss verksamhetsförmåga har för att kunna hantera sina speciella dokument.

Vad behöver vi metadata till?

Man kan säga att dokumentmetadata har fyra syften och behövs för att:

  1. identifiera olika dokument och skilja dem åt.
  2. stödja att vi kan söka och leta bland dokument för att hitta data och information.
  3. säkerställa tillbörlig åtkomst och användning av data och information i dokument.
  4. stödja hantering och administration av dokument över dess livscykel. 

Attribut för generella dokumentmetadata

För vart och ett av de syften som nämndes ovan kan man tänka sig ett antal metadata-attribut som behövs för att stödja just det syftet. Exakt vilka generella metadata-attribut man väljer att ha beror på organisationens art och behov och måste väljas av organisationen själv.

Nedan följer exempel på attribut för generella metadata för dokument som en organisation kan välja att ha. Dessa är sorterade efter vilket syfte de stödjer.

  • Syfte: Identifiera dokument och skilja dokument åt
    • Författare (Author)
      Möjliga värden kan ha en kontrollerad källa, en lista med namn. Den kan eventuellt stödjas av en lista med synonymer för olika skrivsätt. Exempel: ”Peter Tallungs”, ”P. Tallungs”, ”P.T:”. I det fall möjliga författare är samma som alla medarbetare så kan listan med möjliga värden hanteras av organisationens masterdata-funktion.
    • Titel (Title)
      Har regler för antal tecken, men inte någon kontrollerad källa för möjliga titlar.
    • Datum (Date)
      Datum då dokumentet skapades, eller blev färdigt.
    • Format (Format)
      Säger vilken form av data dokumentet innehåller och hur det är kodat.
      Bör ha en kontrollerad källa för möjliga värden.
      MIME är en allmänt förekommande standard som ofta används.
    • Utgivare (Publisher
    • Språk (Language
    • Version (Version
    • Serie: Namn och nummer (Series name and Number
    • Innehållstyp (Content Type)
      Kan ha en kontrollerad källa för möjliga värden att välja från och bör stödjas av en hierarkisk klassificeringsstruktur. Denna struktur är typiskt bred och grund.
  • Syfte: Söka dokument, och bläddra bland dokument
    • Land (Country)
    • Region (Region)
    • Sammanfattning (Abstract/Summary)
    • Nyckelord (Keywords)
      Kan ha en kontrollerad källa för möjliga värden som då bör hämtas från en organisationsgemensam ordbok, lämpligen en så kallad thesaurus. En sådan innehåller de termer som bör användas samt hur de relaterar till varandra inom organisationens domän. Observera att nyckelord inte är samma som ämne.
    • Ämne (Topic/Subject)
      Kan ha en kontrollerad källa för möjliga värden som då bör stödjas av en hierarkisk klassificeringsstruktur. Denna struktur är typiskt bred och grund.
    • Organisationsenhet (Business Function)
      Anger vilken organisationsenhet som ägde informationsobjektet då det lagrades. Bör ha en kontrollerad källa för möjliga värden alla organisationsenheter som organisationen har eller har haft historiskt. Uppsättningen av möjliga värden bör stödjas av en hierarkisk struktur som visar organisationens uppbyggnad både idag och historiskt. Det betyder att strukturen måste underhållas och uppdateras när organisationen ändras, men också att äldre strukturer måste bevaras. Strukturen är typiskt smal och djup.
  • Syfte: Åtkomst och användning
    • Auktoriserad av (Authorized By)
    • Åtkomsträttigheter (Access Rights)
      Vem som har rätt till, eller vilka rättigheter som krävs för att komma åt, ändra eller radera dokumentet.
    • Hemvist (Location)
      Vilken organisationsenhet eller befattning som har ansvar för dokumentet.
    • Användningshistorik (Use History)
      Vem som har använt dokumentet och när.
    • Offentlighetsstatus (Disclosure status)
      Om dokumentet är offentliggjort för tillfället, är avsett att offentlighetgöras i framtiden eller inte är avsett att offentliggöras.
      Möjliga värden är en flat lista med värden definierade av någon auktoritet i organisationen. Alla system inom organisationen bör ha samma uppsättning möjliga värden.
    • Offentlighetsstatus – reviderades – datum (Disclosure Review Date)
      Datum då offentlighetsstatus för dokumentet bestämdes eller ändrades.
  • Syfte: Hantering och administration
    • Post-id (Record Identifier)
      Id för dokument som lagras som poster i en databas.
    • Makuleringsdatum (Disposal Status)
      Datum då dokumentet ska makuleras.
    • Hanteringshistorik (Management History)
      Datum och åtgärd som har gjorts för hantering av dokumentet.
    • Bevarandeplan (Retention Schedule/Mandate)
      Plan eller beslut för hur dokumentet ska bevaras.
    • Bevarandehistoria (Preservation History)
      Datum och åtgärd som har gjorts för bevarande av dokumentet.
    • Aggregeringsnivå (Aggregation Level)
      I det fall dokumentet ingår i en hierarki av dokument, nivån i hierarkin detta dokument befinner sig i.
    • Relation (Relation)
      Namn på den hierarki detta dokument ingår i samt vilket närmast överliggande dokument detta dokument är en del av.

Exempel på utökade dokumentmetadata-attribut

Som sagt behöver specifika typer av dokument även specifika metadata-attribut. Projektdokument kan behöva attribut för projektnamn och typ av projektdokument. Epostmeddelande som ska sparas som allmänt tillgängliga behöver sändare, mottagare och så vidare.

Hur tar jag fram en metadatamodell för vår organisation?

Vilka metadata-attribut ska vi ha för organisationens dokument och vilka ska reglerna vara för varje attribut? Detta behöver varje organisation komma fram till. Det finns ingen ”one size that fits all”. Bästa sättet är att gå igenom de befintliga system som skapar eller hanterar dokument samt ett representativt urval av dokument av olika slag, och hur de behöver hanteras, för att därifrån komma fram till vilka metadata-attribut som passar vår verksamhet.

Sedan är det lämpligt att ta fram en informationsmodell för organisationens gemensamma önskade dokumentmetadata. Modellen uttrycker de krav vi ställer på alla verksamhetsförmågor (och därmed applikationer) som ska skapa eller uppdatera dokument, beträffande vilken metadata de ska kunna tagga dokument med.

Det finns några fällor att se upp med här. En fälla är att tro att man bara utan vidare kan anamma en populär standard, som till exempel Dublin Core. Dublin Core är utformad för att underlätta åtkomst till offentligt publicerade dokument, vilket bara är en del av det vi behöver kunna lösa. Dublin Core säger till exempel inget om de metadata som behövs för livscykelhantering. Man kan absolut använda olika publicerade standarder. Men då bör man först analysera, och förstå sin egen organisations behov. Först därefter kan man se vilka publicerade standarder som passar.

En annan fälla är att anamma en standard för hur man kodar metadata, och därmed tro att man har löst problemet. En kodningsstandard för metadata säger inget om vilken metadata man ska ha bara hur den kan paketeras och utbytas.

Hur kan vi hantera dokumentmetadata?

Hur, var och när ska dokument tilldelas sina metadata och hur ska den sedan göras tillgänglig för de som behöver den? Om vi hanterade organisationens alla dokument i ett och samma system vore det enkelt. Men det är inte realistiskt. Monolitiska lösningar är aldrig något hållbart, och i detta fall mer orealistisk än någonsin. Med tanke på att dokument skapas i så många olika former och i så många olika sammanhang.

Vad vi behöver är ett centralt register för dokument, där de olika applikationerna som skapar och hanterar dokument av olika slag kan registrera dokumenten. Det innebär att själva dokumenten ligger kvar i sina applikationer men en metadatapost för dokumentet registreras centralt. Det blir alltså som ett register i ett bibliotek. Vi har då fått en distribuerad och därmed mer flexibel och realistisk arkitektur. Det enda vi verkligen behöver hantera gemensamt hanterar vi gemensamt, det vill säga metadata.

Hur skapar vi metadata?

Varje gång ett dokument som har någon form av allmänt intresse skapas, ändras eller hanteras behöver metadata om dokumentet skapas eller hanteras. Hur ska det gå till? En del registrerar vi redan idag när vi skapar något, eller bör göra i varje fall. Som titel, datum med mera. En del behöver vi bygga möjligheter för att registrera manuellt. Annat kan vi kanske automatisera, mer eller mindre. Det finns semantiska tekniker av olika slag med regler för att automatiskt skapa metadata utifrån innehållet i ett dokument. Men det är nog orealistiskt att vi idag eller inom en nära framtid ska kunna luta oss mot sådana, speciellt som vi idag i allmänhet inte ens har börjat tänka i termer av hantering av dokument och vilken metadata som skulle behövas och till vad. 

Utkast till en informationsmodell för dokumentmetadata

För att illustrera hur detta kan se ut har jag tagit fram ett utkast till en informationsmodell för dokumentmetadata i en organisation. Se bild sist i denna artikel. Observera att den endast täcker generella dokumentmetadata.

Hur gör ni i er organisation?

Hur hanterar ni dokument? Hur stödjer du som informationsarkitekt dokumenthanteringen? Kanske har du synpunkter som jag har missat här. Jag vill gärna höra dina erfarenheter.

/Peter Tallungs, IRM

#Informationsmodellering, #Information Management, #Dokumenthantering

Vad kan vi lära av den bästa graf som någonsin ritats?

Den amerikanske statistikern och grafikern Edward Tufte har skrivit fem böcker om hur man på bästa sätt förmedlar information och kunskap med hjälp av grafik. Den 150 år gamla grafen ovan är med hans ord: ”Probably the best statistical graphic ever drawn”.  Men vad menar han med det? Vi som gör modeller kan lära oss något här.

Grafen i fråga är en schematisk karta som visar de succesiva truppförflyttningarna under Napoleons ryska kampanj 1812–13, det vill säga den franska invasionen av Ryssland. Den har staplar för flöden och är av en typ som vi idag kallar för flödeskarta. Den är ritad av den franske arméingenjören Charles Joseph Minard år 1869. Minard räknas idag som en av de som betytt mest för utvecklingen av statistisk grafik, det vill säga hur man presenterar numeriska värden med hjälp av diagram.

Vad Minards graf visar

Charles Minard som ritade grafen

Grafen är alltså till sin grund en schematisk karta. Längst till vänster ser vi floden Njemen, vid polsk-tyska gränsen, som en tunn slingrande nord-sydlig linje. Där samlade fransmännen i juni 1812 den största arméstyrkan dittills i historien, 422 000 man av många nationaliteter. Den ljusröda stapeln visar hur den franska armén rycker fram mot Moskva, och den svarta stapeln visar återtåget från Moskva ett halvår senare. Bredden på den ljusröda och den svarta stapeln representerar styrkans storlek och antalet man vid tillfället. Vi kan se hur stapeln smalnar av när man tågar österut. Ryssarna brände foder, säd och ibland hela bondbyar i förväg så att den gigantiska armén fick svårt att föda sig. Kosacker anföll i små snabba attacker, dag som natt. Vi kan se i grafen hur man skickade ut hjälptrupper för att försöka ta itu med kosackförband och skydda flanken (sidan) och kön (bakändan) av denna marscherande jättekoloss.

Ryssarna hade två stora arméer men undvek direkt batalj och drog sig undan hela tiden. Dels på grund av att de två generalerna inte riktigt samarbetade, men också av klok taktik. Så Napoleon fick inte till den drabbning han hade tänkt sig. Han skickade förgäves propåer till tsaren att komma och göra upp. Strax före Moskva möttes man dock till slut i ett slag, slaget vid Borodino, som Tolstoj skildrar i ”Krig och Fred”. Borodino blev inte till ett avgörande utan fransmännen intog Moskva med de 100 000 man som man hade kvar. Huvudstaden var folktom, befolkningen hade utrymts, och tsar Alexander vägrade att skriva på något avtal så inte heller detta kunde ses som en seger. Staden råkade i brand, vintern var på väg och Napoleon tvingades att vända hemåt i oförrättat ärende.

Den svarta stapel som visar reträtten under vintermånaderna är länkad till en temperaturskala i nederkanten. Det var mycket kallt, man svalt och frös. Man kan se hack där stapeln plötsligt blir smalare. Det var vid flodövergångar som innebar förluster. Man rev bondgårdar för att få bromaterial. En sådan övergång kunde ta flera dagar. Kosacker anföll under tiden och det blev ofta panik på bron. Soldater och vagnar, tungt lastade med byte, försvann ner genom isen.

Till slut, sex månader efter man lämnat Moskva var det en spillra på 10 000 man som sågs komma tillbaka över isen på Njemen. Det står en notering i grafen: ”Kosackerna korsar den frusna Njemen i galopp, när de driver ut de spridda resterna av Napoleons stora armé.”

En flodövergång blev särskilt dramatisk: 28 november: Övergången över Berezina.

Häftigt ansatta av fienden kom fransmännen till floden Berezina i närheten av Borisov utan medel att komma över, eftersom Napoleon hade låtit bränna upp hela sin broträng bara sex dagar tidigare. Man skaffade material genom att riva ett par hus vid stranden, och vid Studianka, 40 km ovanför Borisov, slogs under stora svårigheter två broar med bockar såsom stöd. Övergången försiggick i tämligen god ordning, tills ryssarna började anfalla på morgonen 28 november, båda 9:e kåren som skulle skydda övergången och de redan överkomna trupperna.

Då uppstod bland de under föregående natt anlända hoparna av marodörer med hästar och vagnar en förfärlig oreda och trängsel, varunder tusentals människor klämdes ihjäl, nedtrampades eller drunknade bland drivisen i floden.

Marskalk Victor, som kommenderade eftertrupperna, drev flera gånger fienden tillbaka och räddade hären från fullständig undergång. Den 29e på morgonen stacks broarna i brand. De som inte kommit över, rusade i förtvivlan ut på de redan brinnande broarna. Många omkom därvid i lågorna eller i floden. Fransmännen förlorade under dessa dagar 10 000 fångar och en stor del av trossen, men blott några få kanoner. Av 70 000 man kom endast 40 000 över floden.

Medurs från övre vänstra hörnet: Slaget vid Borodino av Louis-Francois Lejeune, Napoeon ser Moskva brinna av Albrecht Adam Marshal, Ney vid slaget vid Kowno av Auguste Raffet, Den franska reträtten av Illarion Pryanishonikov.


Medurs från övre vänstra hörnet: Slaget vid Borodino av Louis-François Lejeune, Napoleon ser Moskva brinna av Albrecht Adam Marshal.  Ney vid slaget vid Kowno av Auguste Raffet, Den franska reträtten av Illarion Pryanishnikov.

Minard hade ett budskap med grafen, att visa hur meningslöst krig var, genom att visa hur många meningslösa förluster fälttåget förde med sig.

Varför är Minards graf så bra?

Detta var bakgrundshistorien. Nu till det egentliga ämnet. Varför anser Edward Tufte att Minards graf är så bra? Tufte har ägnat sitt liv åt att fundera på hur man på bästa sätt gör antal och mängder begripliga med hjälp av grafer av olika slag. Han sammanfattar det han kommit fram till i sex principer. I sin bok ställer han Minards graf mot dessa principer, och resultatet är följande.

Princip 1: Visa jämförelser, kontraster och skillnader

Den fundamentala frågan att besvara i statistisk undersökning är ”Jämfört med vad?”. Det viktiga är att göra intelligenta och relevanta jämförelser.

Minards flödeskarta visar framför allt hur och när de franska truppstyrkorna decimeras. Vi kan jämföra bredden av flödeslinjen vid olika punkter för att få föreställning om hur stor skillnaden är vid olika tidpunkter.

Princip 2: Visa orsakssammanhang, mekanismer, förklaring, systematisk struktur

Orsakerna till varför soldaterna blir färre är kanske inte framgår så tydligt i Minards flödeskarta. Men vi ser till exempel att vinterkylan (i motsats till vad som ofta påstås) inte var någon huvudorsak till det franska debaclet. Men Minard visar i varje fall en möjlig orsak till just de förluster som sker under återtåget: vinterkylan. Temperaturskalan är i Réaumur som har samma nollpunkt som Celsius men där 10 grader Réaumur = 12,5 grader Celsius.

Princip 3: Visa multivariabel data, det vill säga sambandet mellan flera variabler som var och en representerar en dimension

Det är när man ställer samman olika dimensioner i en och samma graf som den blir intressant, menar Tufte.

Minard sammanför flera dimensioner av data som tillsammans berättar en historia.

Minards graf har följande fem dimensioner, det vill säga typer av data, som den sammanställer:

  • Var – Geografin, det vill säga var armén befinner sig vid varje tillfälle. Dels genom att det finns en tänkt ej utritad nord-syd- och ost-väst-skala och dels genom att vissa orter och floder är utmärkta.
  • Storleken av armén – Vid varje tillfälle, antal soldater, dels som bredden på stapeln, dels med siffror bredvid stapeln.
  • Framryckning eller reträtt – Röd eller svart stapel.
  • När – Datum vid tillfället.
  • Temperaturen – Vid tillfället (under återtåget endast).

De fem variablerna, eller dimensionerna, visas med distinkt klarhet. Det finns ingen jargong eller dimridåer i grafen menar Tufte.

Nästan alla de intressanta sammanhang vi försöker förstå är multivariabla till sin natur. Tufte pratar om ”escaping flatland” det vill säga att man med olika grafiska medel försöker visa fler dimensioner i sina grafer än de som den tvådimensionella ytans två axlar ger en direkt möjlighet till.

Princip 4: Integrera text, siffror, bilder och diagram fullständigt

Minard menar att det är viktigt att kombinera olika presentationsformer och att verkligen göra det i samma bild. Text och bild stödjer varandra och kommunicerar tillsammans mera effektivt än var och en för sig.

Minard kombinerar olika presentationsformer i samma bild. Karta, staplar som bildar flödeslinjer, text, samt statistiskt diagram (temperaturskalan i nederkanten).

Minard använder sig av en ljus, tunn omättad färg på flödeslinjen för att ortnamnen ska synas igenom. Det är en teknik som är vanlig i kartor.

Princip 5: Dokumentera

Tufte framhåller att trovärdigheten i en presentation är beroende av kvaliteten och integriteten hos upphovsmannen och dennes källor. Därför är det viktigt att presentationen har dokumentation så man som läsare kan bedöma innehållet. Det är inte bara författare som ska namnges utan även sponsorer så att man kan bedöma intressen och agendor bakom presentationen. Man bör även redovisa källor, noggrant redovisa skalor och andra detaljer.

Minard har tagit med följande dokumentation:

  • Titeln – Säger vilken typ av graf det är: figurativ karta och vad det avbildar: De successiva truppförlusterna hos franska armén under den ryska kampanjen 1812–1813. Tufte menar att vi alltid bör sätta en noggrann och detaljerad titel på det vi producerar.
  • Vem som har gjort grafen
  • Namn och befattning
  • När och var den gjordes
  • På vems uppdrag och bekostnad
  • Vilka källorna är – Minard namnger fem källor. Informationen kommer alltid från någon. Läsaren bör informeras om vem.
  • Antaganden som gjorts
  • Förklaring av färgkodning och skalor
  • Beskrivning av vad grafen vill visa
  • Vem som tryckt och publicerat grafen.

Vi glömmer ofta att ange den typen av metadata i våra modeller. Det är viktigt för att rätt kunna bedöma och använda en graf, speciellt i efterhand.

Om man publikt anger författarskap så signalerar det till läsaren att någon har tagit ansvar för analysen. Och omvänt, frånvaron av uppgift om författare signalerar att man inte står för det grafen visar. Läsare kan ta kontakt med namngivna författare. Och det räcker inte med företagsnamn. Det är människor som gör saker inte företag. Minard signerade alltid sina grafer. Odokumenterade presentationer är alltid suspekta, menar Tufte.

Princip 6: Innehåll är viktigast

Minard lyfter fram data, låter det tala för sig själv. Det finns inga onödiga dekorationer eller effekter. Allt som är där är data. Han använder minsta möjliga bläck. Färgsättningen är sparsmakad. Den röda färgen är tunn och transparent. (Det är en viktig princip att använda så lite bläck dom möjligt för att presentera så mycket data som möjligt. Tufte kallar det ”black-ink-ratio”. )

Det effektivaste sättet att förbättra en graf är att se till att få bättre data. Dekoration kan aldrig rädda dåligt innehåll. Allt som är där, är där för att lyfta fram innehållet.

Grafen har ett budskap, ett ärende, den berättar en historia. De bästa graferna har en tydlig idé om vad de vill visa. Minard nämner inte ”Napoleon”. Han är gammal soldat och vill visa vad ett fälttåg betyder i praktiken för soldaterna, de skadade, döda, tillfångatagna och deserterande.    

Tufte har gjort Minards graf viral

Tufte har gjort Minard och framförallt denna graf berömd. Studenter på statistikutbildningar beställer te-koppar med Minards graf som motiv. Det händer att man har Minards graf som tatuering.

Det finns också de som har försökt förbättra grafen med hjälp av moderna medel som tredimensionella tekniker. Men jag har inte sett något som jag tyckt varit lyckad. Detta visar att vi inte behöver avancerade tekniker för att göra riktigt bra presentationer.

Vad kan vi lära oss? Så här tillämpar jag Tuftes sex principer.

För många år sedan, på jakt efter sätt att utveckla hur vi gestaltar modeller, plöjde jag Tuftes böcker. Jag tycker att hans principer har hjälpt mig. Det har stärkt mig i mina egna försök och tankar. Jag menar att dessa är i högsta grad tillämpliga även för oss som inte gör statistiska grafer utan informationsmodeller, förmågekartor och liknande. Jag ska försöka formulera och exemplifiera på vilket sätt jag har använt mig av dessa principer.

Du kan se resultat av detta i exempel i många tidigare artiklar jag skrivit, även om jag inte alltid refererat till Minard och Tufte. Och fler artiklar kommer framöver. Kanske kan detta också inspirera dig som läser detta.

  • Tillämpning av Princip 1: Visa jämförelser, kontraster och skillnader.
    Många verksamheter jag arbetat i har haft flera parallella produkt- eller avtalsstrukturer, eller liknande. En del har slagit samman flera företag men ändå fortsatt med separata produktstrukturer. Då har vi skapat en gemensam generisk produktstuktur för att kunna ha en gemensam rapportering och uppföljning. Men vi har ändå behållit de lokala strukturerna för den operativa användningen. Då har de olika delarna av verksamheten fått översätta till den gemensamma begreppsapparaten och strukturerna i sin rapportering. Då har det varit viktigt att i informationsmodellen parallellt visa både de olika lokala strukturerna och samtidigt den generella. Då har jag i ER-diagrammet ritat de olika strukturerna parallellt bredvid varandra så man tydligt ser vilka begrepp som har motsvarighet och ibland att det saknas motsvarighet. Det har varit mycket värdefullt och jag har svårt att se hur man skulle kunna hantera det bättre.    
  • Tillämpning av Princip 2: Visa orsakssammanhang, mekanismer, förklaring, systematisk struktur
    Orsakssammanhang kanske inte är direkt synliga i den typen av modeller jag och mina kollegor gör, vad jag kan komma på. Men mekanismer, förklaringar och systematiska strukturer går till kärnan av det vi visar.   
  • Tillämpning av Princip 3: Visa multivariabel data
    Det här är samma som att våra modeller kan, om vi är skickliga, ordna de företeelser vi beskriver i flera dimensioner samtidigt. Det är viktigt att vi utvecklar den förmågan. Riktigt intressanta grafer ställer samman flera dimensioner säger Tufte, och jag håller med. Jag kommer att ge exempel på detta i senare artiklar.
  • Tillämpning av Princip 4: Integrera text, siffror, bilder och diagram fullständigt
    Jag strävar efter att kombinera text (strukturerad text) och diagram (olika slags diagram) så mycket det bara går. Jag har visat exempel på detta i en artikel om detta ”Informationsmodellering – Integrera text och grafik” som publicerades 2022-06-23.
  • Tillämpning av Princip 5: Dokumentera
    Det här är något jag försöker tänka på. Ett sätt att tänka är att en modell alltid är ett dokument och ett dokument har alltid sådan metainformation: Titel, vem som har gjort dokumentet och när, vad det handlar om och så vidare.
  • Tillämpning av Princip 6: Innehåll är viktigast
    I artikeln ”Maximera innehållet – men snåla med bläcket!” publicerad 2022-06-16 har jag skrivit mer om Tuftes idé runt en minimalistisk design och också givit exempel på hur jag tillämpat detta. Det är den ena sidan av principen, att inte skymma det viktiga innehållet med onödigt bläck. Den andra sidan av principen, att man ska ha något viktigt att visa över huvud taget, det är ett helt annat ämne som går till botten med vad vi gör som informationsarkitekter och varför. Hur ska jag kunna en kort och enkel behandling av det ämnet? Jag tror att det är bäst att hela denna artikelserie på till dags dato 64 artiklar får ge svar på vad min syn är om detta.

Vad tror du?

Vad säger du om Tuftes sex principer? Saknar du någon? Vilka principer tillämpar du när du modellerar? Hur resonerar dina principer med Tuftes?

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 25 augusti. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Informationsmodellering: Integrera text och grafik

En modell – informationsmodell eller annan modell – är inte komplett förrän den är gestaltad i både grafik och text. Och vi bör sträva efter att integrera texten och grafiken så långt det är möjligt.

Det vanliga är att en informationsmodell endast görs som ett ER-diagram. Så vanligt att många till och med sätter likhetstecken mellan informationsmodell och ER-diagram. Ibland kan diagrammet åtföljas av text vid sidan av. Men då ser man vanligen inte texten som en fullvärdig del av modellens gestaltning utan som en bifogad förklaring av modellen. Skillnaden kan tyckas subtil men är avgörande menar jag, för vår förståelse av vad en modell är.

En komplett modell bör vara gestaltad i både diagram och text

Jag menar att en informationsmodell bör vara gestaltad i både text och grafik. Det är sant att en bild säger mer än tusen ord. Men det är likafullt sant att en text säger mer än tusen bilder. Och ännu mera sant att med text och bild tillsammans så får vi en synergi som når ännu längre i tydlighet och klarhet. När vi behöver uttrycka oss både visuellt och verbalt, blir det inte bara tydligare utan vi kan även tänka klarare.

Modeller är våra centrala verktyg. Och hur vi gestaltar dem är avgörande för hur effektiva de blir, både som analys- och tankeverktyg i sig själva samt för att kommunicera det vi kommit fram till. Vi bör därför använda oss av alla till buds stående medel för att gestalta våra modeller. Då behöver vi både diagram och text, samt att vi låter diagram och text stödja varandra så mycket det bara går.

Diagram är för informationsmodeller först och främst alltid ett eller flera ER-diagram av något slag. Men också andra typer av diagram kan behövas, så som förekomstdiagram (instance diagrams) och tillståndsdiagram (state charts). Text innebär strukturerad text av olika slag.

Den amerikanske statistikern och grafikern Edward Tufte, som jag nämnt i tidigare artiklar, menar att detta är viktigt. De grafer som vi gör för att förmedla data, information eller kunskap, bör ha texter som är så tätt integrerade med själva grafen som det bara går. Bild och text ska samverka tätt.

Historien om förhållande mellan text och bild

Varför är vi så inställda på att separera text och bild? Det har nämligen inte alltid varit så. Det finns en historisk förklaring sägs det. Före den moderna tiden, före tryckkonsten, då man alltid skrev och ritade för hand var det vanligt att text och bild följdes åt på ett fullständigt integrerat sätt. Text och illustrationer löpte tillsammans på samma sidor i dokumenten.

Se exempel bild I och II nedan.

Bild I: Nicolaus Copernicus: Diagram som illustrerar den heliocentriska teorin om solsystemet, cirka 1520.
Bild II: Leonardo da Vinci: Penna-och-bläckstudier av mänskligt foster, cirka 1510.

När så tryckkonsten kom på 1500-talet blev det tekniskt omöjligt att integrera text och bild på det sättet. Boktryckare tryckte text med hjälp av typer, först i trä och sedan i bly. Bildsnidare och gravörer tryckte bilder med hjälp av träsnitt och graverade plåtar. Bokbindare band ihop det hela till böcker. Illustrationerna hamnade på det sättet för sig själva i slutet av bandet.

Integrera text och bild!

Idag är vi fria från den begränsningen som tryckerikonsten orsakade. Vi har nu teknik som ger oss alla möjligheter att kombinera text och illustrationer.

Men det finns en tröghet som låter föreställningen att vi ska hålla isär text och illustrationer leva kvar. I de modeller jag möter ser jag nästan alltid diagram för sig och text för sig.  I de lyckliga fall det finns text över huvud taget vill säga.

Men låt oss släppa den vanföreställningen och börja integrera text och bild.

Hur integrerar vi text och bild

Text och diagram ska samverka, vilket innebär att de behöver visas och hanteras tillsammans så gott det går.

Microsoft Word är ett utmärkt verktyg för att sätta samman text och bild till en helhet. Fast det fungerar bara för mindre diagram, som ryms på samma sida som åtföljande text.

I övrigt kan vi se till att ha förklarande texter i och i anslutning till våra diagram där så är lämpligt.

Exempel från informationsmodeller

Jag har i olika sammanhang strävat efter att integrera text och bild så mycket det går för att få till modeller som förmedlar mer kunskap och gör det på ett tydligare sätt. Jag visar i det följande några exempel från informationsmodeller som jag jobbat med i olika sammanhang. Jag vill visa hur man kan göra och vill också illustrera att det inte finns ett sätt utan vi måste vara kreativa och göra på olika sätt i olika sammanhang.

Bild III: Utsnitt av informationsmodell från bank: Förekomstdiagram med förklarande text. Modellen visar med exempel hur olika lokala avtalsstrukturer översätts till en global, för analys och rapportering.
Bild IV: Utsnitt av informationsmodell från försäkringsbolag: Förekomstdiagram med förklarande text. Förklarar med exempel de två olika typfallen av motorfordonsförsäkring.
Bild V: Utsnitt av informationsmodell från försäkringsbolag: ER-diagram med förklarande text. Förklarar hur försäkringsvillkor förekommer på olika nivåer i produkt- och avtalsstrukturen.
Bild VI: Utsnitt av informationsmodell från försäkringsbolag: ER-diagram med förklarande texter. Förklarar hur beloppen för skadeutbetalningar, premievolymer och försäkrade belopp rapporteras centralt.
Bild VII: Utsnitt av informationsmodell: ER-diagram med förklarande texter. Presenterar förslag på modell för bonushantering på en bank.
Bild VIII: Utsnitt av informationsmodell från bank: Beskrivning av möjliga värden för attributet som visar vilket tillstånd ett kundavtal befinner sig i. Hur tillstånden kan följa varandra över tid visas med ett tillståndsdiagram.
Bild IX: Utsnitt av informationsmodell från bank: Utsnitt av en scenariobeskrivning med text och åtföljande förekomstdiagram. Visar i en serie av händelser hur en dispyt om en betalningstransaktion hanteras.

Ett av många sätt för bättre modeller

Som sagt, för oss arkitekter är modeller av olika slag de centrala verktygen. Vårt jobb kokar ner till att analysera och beskriva verksamheter med hjälp av modeller av olika slag. Och att använda dessa modeller för att hjälpa och guida alla dessa som tillsammans utvecklar våra verksamheter.

Detta med att integrera text och bild är bara ett av många områden jag menar att vi behöver utveckla för att göra bättre modeller, de vill säga modeller som tjänar oss bättre i vårt arbete. Övriga idéer hittar du i de tidigare artiklarna jag skrivit, och mer kommer framöver.

/Peter Tallungs, IRM

Nu tar denna artikelserie ett sommaruppehåll. Nästa artikel publiceras i mitten av augusti. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Maximera innehållet – men snåla med bläcket!

Om vi ska göra riktigt bra modelldiagram bör vi behärska uttrycksmedlen. Grundläggande är hur vi dimensionerar linjer, typsnitt och färger.  Den kände amerikanske grafikern och statistikern Edward Tufte har skrivit en serie böcker om hur man använder grafik för att förmedla data, information och kunskap. Han förespråkar en minimalism i uttrycket.

Edward Tuftes idé om maximal information med minimal mängd bläck

Edward Tufte menar att varje uns bläck i en graf ska finnas där av en anledning. Om den inte tillför någon information ska den ovillkorligen tas bort.

Först och främst ska allt som bara är dekor bort. Sedan ska vi använda så tunna linjer som möjligt. Färg ska vi bara använda då den verkligen har betydelse, och då i så ljus nyans som möjligt. På så sätt finns det inget som skymmer och våra grafer blir tydligare. Vi nyttjar då de grafiska uttrycksmedlen effektivt och ändamålsenligt för att förmedla informationen.

Däremot då det gäller innehållet, det vill säga vilken information som förmedlas, förordar han motsatsen till minimalism. Vi ska kombinera så mycket kunskap som möjligt i en graf. Det är då en graf blir riktigt intressant. Alla riktigt intressanta grafer sammanför och kombinerar flera olika dimensioner.

Tufte har infört begreppet ”Data-Ink Ratio”, det vill säga en tänkt kvot mellan det bläck som verkligen förmedlar någon data i en graf och den totala mängden bläck som använts. Den kvoten ska hållas så hög som möjligt. Det innebär att vi ska anstränga oss att få in mer data, information och kunskap i våra grafer utan att använda mer bläck än vi behöver. Likaså ska vi försöka minska mängden bläck utan att förlora information.

En onödigt stor mängd bläck kan betyda onödigt tjocka linjer, för mycket svärta i linjerna, onödiga linjer eller detaljer som inte fyller någon funktion utöver att vara dekorativa. Det kan också betyda att vi använder färg där den inte tillför något som inte kan förmedlas på ett enklare sätt. Eller att vi använder en kraftig färg där en ljusare nyans skulle göra jobbet.

Edward Tuftes exempel

I sin första bok om informationsdesign, The Visual Display of Quantitative Information från 1983, exemplifierar Tufte detta med ett tänkt exempel.

Han utgår från ett stapeldiagram där han i fem steg tar bort grafiska element utan att minska datainnehållet.

Det första han gör är att ta bort onödiga stödlinjer i bakgrunden. Sedan tar han bort den blå bakgrundsfärgen som ju faktiskt inte tillför något. ”Chart-junk” (diagramskräp) är vad han kallar riktigt dåliga exempel på onödiga grafiska element. I nästa steg ryker ramlinjen på två sidor, den övre och den högra. Därefter ramlinjen på vänstra sidan, fast han ersätter på samma gång de horisontella stödlinjer han tog bort tidigare med horisontella slitsar i staplarna. Till sist tar han bort ramlinjen i underkant.
Det här kanske är ett lite väl extremt exempel, men illustrerar ändå hur vi kan ifrågasätta grafiska element och plocka bort dem när de inte tillför något.

Många av de mer avskräckande exempel på chart-junk har Tufte hittat från sammanhang då upphovspersonen inte har kunnat bärga sig från att leka med datorgrafiken. Här ser vi en karta med Nordmakedoniens regioner. Illustratören har använt olika blåa färger för landets regioner. Dessutom har hen tyckt det varit snitsigt med en färggradient i varje fält. Varken färgerna eller gradienterna tillför någon information över huvud taget.

Vad betyder det för oss

Hur kan vi tillämpa Tuftes tänk i de diagram vi designar: ER-diagram, förekomstdiagram, tillståndsdiagram, förmågekartor, processdiagram med mera?

Jag gör så här:

  • Linjer
    Jag ritar så tunna linjer jag kan, och byter svarta linjer mot mörkgrå när det är något jag vill hålla ur fokus. På så sätt spar jag den kraft som ligger i den svarta färgen till när den behövs, det vill säga när jag vill rikta fokus mot något särskilt element. Att rita tjocka svarta linjer i onödan är som att ständigt skrika. Vi utnyttjar då inte den möjlighet till dynamik vi har oss till buds.
  • Texter
    Jag fetmarkerar text endast då jag vill lyfta fram något som rubriker och liknande. Och de texter jag vill tona ner skriver jag i grått.
  • Färgade linjer och texter
    Jag spar färger till när de verkligen behövs. Färger är kraftfulla grafiska medel. Därför bör de användas med måtta och sparas till de tillfällen då de tillför något. Varje färg måste då ges en mening, någon egenskap man vill förmedla. I annat fall behövs den ju inte. Färger är en begränsad tillgång som betydelsebärare. Eftersom olika nyanser av samma färg inte tydligt kan skiljas från varandra återstår det inte så många kulörer som vi kan använda. För linjer och texter mot en ljus bakgrund fungerar endast kraftiga kulörer. Då har vi förutom svart och mörkgrått, endast blå, grön, röd och mörkgul att tillgå.
  • Färgade ytor
    Färgade ytor behöver man sällan, oftast tillför de inget. Men där man ska färglägga ytor bör man välja mycket ljusa färger, annars slår de emot en med alldeles för stark effekt.

Fortsättning följer

Jag kommer att berätta mer om Edward Tuftes idéer framöver och hur de kan hjälp oss att göra bättre modeller. Bland annat kommer jag berätta om vikten av att integrera text och grafik, samt om hur vi kan få riktigt intressanta modeller genom att sammanställa olika dimensioner i en och samma graf.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 23 juni. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Informationsmodellering: Om verksamhetsregler

Verksamhetsregler har sin naturliga plats i informationsmodellen. Då beskriver man inte bara allt det som verksamheten hanterar utan också vilka regler som gäller för detta. På det sättet fångar man hela den operativa verksamhetslogiken.

Verksamhetsregler har sin naturliga plats i informationsmodellen. Då beskriver man inte bara allt det som verksamheten hanterar utan också vilka regler som gäller för detta. På det sättet fångar man hela den operativa verksamhetslogiken.

/Peter Tallungs, IRM, 2022-06-09

Verksamhetsregler styr hur en verksamhet ska fungerar dagligdags. Därmed kan man tro att verksamhetsregler hanteras på ett strukturerat sätt i våra verksamheter, att de dokumenteras, vårdas, hanteras och tillgängliggörs för de som behöver dem.

Men så är det knappast. Få organisationer har något sätt att hantera sina verksamhetsregler. Jag har aldrig sett någon kurs eller ramverk för verksamhetsarkitektur som haft någon praktisk genomförbar idé för detta.

I sammanhang där verksamhetsarkitektur behandlas undviker man ämnet. Man nämner kanske att verksamhetsregler är viktiga men går inte in på vad de är eller hur de kan hanteras.

Men låt oss ta tag i ämnet, här och nu! Vi börjar med att titta på vad verksamhetsregler är.

Vad är en verksamhetsregel?

För att du ska få en känsla för vad vi pratar om ges här några exempel på verksamhetsregler.

”Att en student är behörig innebär att studenten har en styrkt behörighet.”

”Endast behörig student får antas till kurs.”

”Endast registrerad student kan få betyg på kurs.”

”En kund måste registreras i kundregistret innan order relaterade till kunden kan skapas.”

”En kund som har order knuten till sig kan inte tas bort.”

”En kund tillåts inte att lägga ny order om kunden inte har en godkänd kredit.”

”En kund som lägger order för mer än 500 SEK får gratis frakt.

”En kund som lägger order under årets kampanj får 20 procents rabatt.”

Vad är verksamhetsregler? – Enkelt förklarat

Verksamhetsregler är de specifika regler som verksamheter ständigt tillämpar i sin operativa verksamhet. En del är mer eller mindre permanenta, andra är tillfälliga. Varje verksamhet har ett otal sådana regler, fast ofta slarvigt hanterade eller oskrivna eller dolda på olika ställen eller otydliga. Därför sker ofta missöden i den dagliga hanteringen.

Vad är verksamhetsregler? – Teori

Det finns gott om teori runt verksamhetsregler. Det var ett hett ämne inom verksamhetsutveckling under 00-talet, men verkar ha gått i stå i brist på exempel på praktisk tillämpning. De som skrev och pratade mycket om ämnet var ett gäng framträdande personer vars idéer gick under baneret ”The Business Rules Approach”. Mest kända var kanske Donald G. Ross och Barbara von Halle. Jag tycker de framförde vettiga saker, och jag följde dem noga. Det som var vettigt var dock endast teorin. Då det gällde hur man rent praktiskt skulle hantera verksamhetsregler var idéerna svagare.

Wikipedia ger följande beskrivning av verksamhetsregler, översatt till svenska av mig:

”Verksamhetsregler beskriver de operationer, definitioner och begränsningar som en organisation behöver tillämpa för att nå sina mål.

Till exempel kan en verksamhetsregel säga att en kreditkontroll inte behöver göras för en återkommande kund. Andra exempel är en lista på utvalda leverantörer eller leveransscheman.

Dessa regler används för att organisationen bättre ska uppnå sina mål, kommunicera mellan medarbetare och intressenter, kommunicera med tredje-parter, visa hur man fullföljer legala krav, opererar mer effektivt, automatiserar hantering, göra analyser med mera.

En definition som har använts är följande: En verksamhetregel är ett uttryck som definierar eller begränsar någon aspekt av verksamheten.”

Om själva namnet ”Verksamhetsregler”

På engelska heter det vi här talar om Business rules. Ofta översätts det till svenska med affärsregler. Men jag menar att det är en felaktig översättning som leder tanken fel. Business kan betyda två olika saker. Det kan betyda affär och det kan betyda verksamhet.

Verksamhet är allt en organisation, del av en organisation eller flera samverkande organisationer gör, stort som smått.

Affär däremot handlar bara om det mest grundläggande eller yttersta aspekterna hos verksamheten; För vilka finns vi till? Hur når vi dem? Vad gör vi för dem? Hur fortsätter vi att vara relevanta?
Många skulle säga att det handlar om pengar. Fast det är ju bara ett mått som används. Det finns viktigare aspekter av en affär. Man kan mycket väl prata om affär också i icke-kommersiella organisationer. En förening, kommun eller statligt verk behöver på samma sätt finnas till för några och vara relevant.

Så anledningen till att jag tycker att Business i många fall bör översättas till verksamhet och inte affär är att det är att det senare är ett specifikt begrepp som är avgränsat till de existentiella frågorna för en organisation.

Vad är inte verksamhetsregler?

Det finns en annan typ av regler som ibland förväxlas med verksamhetsregler men som bör benämnas och hanteras på ett annat sätt. Det är bestämmelser, styrande regler, policys, affärsbestämmelser med mera. Både sådana som påläggs verksamheter utifrån och sådana som organisationer tar fram själva.

Allt sådant hör hemma i strategisk ledning och ska inte hänföras till det som menas med verksamhetsregler som är mer direkt operativa. Verksamhetsregler är ett av de medel med vilka strategier är implementerade. Verksamhetsregler säger en organisation vad som går att göra i den detaljerade operativa hanteringen medans strategin fokuserar på organisationens inriktning på makronivå.

Man kan också uttrycka det på följande sätt: Strategi ger organisationen en riktning i vad den ska göra. Verksamhetsregler ger detaljerad styrning om exakt hur en strategi ska översättas till handling i en specifik situation.

Principer för hur vi ska hantera verksamhetsregler

Verksamhetsregler är viktiga för en verksamhet och behöver därför hanteras. Vad innebär hantering i detta fall? Nedan principer för detta togs fram av gänget bakom The Business Rules Approach.

Verksamhetsregler ska

  • vara nedskrivna och tydliggjorda.
  • uttryckas i naturligt språk.
  • utformas så de inte är bundna till specifika procedurer och arbetsflöden.
  • beskrivas diskret, icke-redundant och icke-procedurellt.
  • bygga på fakta, begrepp och termer.
  • vara åtkomliga för de som behöver dem.
  • Hanteras.

Typer av verksamhetsregler

En verksamhetregel ska formuleras så den blir atomär, vilket betyder att den ska vara på sådan detaljnivå att den inte kan brytas ner i fler detaljerade regler utan att information förloras.

Varje (atomär) verksamhetregel måste vara någon av följande typer:

  • Strukturregel (Structural assertion)
    Ett definierat begrepp eller redogörelse av fakta som uttrycker någon aspekt av någon struktur i verksamheten. Det omfattar både termer och fakta sammansatt av dessa termer.
  • Handlingsregel (Action assertion)
    En begränsning eller villkor sombegränsar eller styr en handling i verksamheten.
  • Härledd regel (Derivation)
    Ett uttryck för kunskap som är härledd från annan kunskap i verksamheten.

Verksamhetsregler i informationsmodellen

Grafen nedan visar hur jag menar att de olika typerna av verksamhetsregler uttrycks i en informationsmodell. Många av reglerna är sådana som vi uttrycker i själva strukturen. Andra regler behöver vi uttrycka i text. För handlingsregler och härledda regler blir textdelen av informationsmodellen särskilt viktig.

Informationsmodellen är platsen för alla verksamhetsregler

Jag menar att den struktur som bäst hanterar verksamhetsregler är informationsmodellen. Detta av två orsaker:

  • Verksamhetsregler är överlappande och tätt förknippade med det som informationsmodellen beskriver i övrigt
    Ty informationsmodellen beskriver inte information i första hand menar jag. Den beskriver de företeelse som verksamheten hanterar samt reglerna för detta, det vill säga strukturer, begränsningar med mera. Detta är en del av verksamhetsreglerna. Andra verksamhetsregler uttrycks i text, och de använder alla de begrepp som definieras i informationsmodellen. Därför är det svårt att separera verksamhetsreglerna från informationsmodellen.
  • Informationsmodellen ger en naturlig struktur för verksamhetsreglerna
    En rik informationsmodell är strukturerad i ämnesområden som i sin tur är indelade i ett avsnitt per entitet. Varje avsnitt för en entitet är sedan indelad i ett underavsnitt per attribut. En verksamhetsregel handlar alltid om en viss entitet eller attribut eller i vissa fall relationen mellan två entiteter eller attribut. Därmed har varje verksamhetsregel en naturlig plats i informationsmodellen. Till exempel finns då allt som gäller för kunder under avsnittet ”Kund”. Inte bara alla definierade begrepp och termer som har med kunder att göra och vilken information som hanteras och var den hanteras. Utan också alla de regler som gäller för hanteringen av kunder.

Informationsmodellen kan bli bärare av hela den operativa verksamhetslogiken

Jag menar att våra informationsmodeller på detta sätt kan bli bärare av hela den operativa verksamhetslogiken. Detta då en informationsmodell kan beskriver både allt det som verksamheten hanterar och vilka regler som gäller för denna.

Det som inte beskrivs av informationsmodellen är av vem och var hanteringen sker. Inte heller varför. Men detta är i sig inte heller del av den operativa verksamhetslogiken, utan snarare hur denna exekveras. Det har vi andra modeller för.

Men om informationsmodellen ska kunna bära hela denna operativa verksamhetslogik krävs det att vi gör på rätt sätt, både i hur vi bygger upp vår modell och hur vi arbetar med den i verksamheten.

Jag har varit med om det i olika verksamheter, så jag vet att det är praktiskt genomförbart och har sett den stora nyttan det ger. Hur man som informationsarkitekt kan driva detta är i själva verket det jag egentligen vill förmedla med hela den här artikelserien.

Men allt detta förutsätter att vi, förutom att vi blir bra på att fånga, formulera och hantera verksamhetsregler

  • gör rika informationsmodeller, det vill säga modeller som inte bara är ett ER-diagram utan integrerar text och bild, och bär mer kunskap än vanligt.
  • verkligen utvecklar och använder våra modeller i en kontinuerlig dialog tvärs över verksamhet och it.

Hur gör ni?

Hur hanterar ni verksamhetsregler i er verksamhet? Hur hanterar och förmedlar ni verksamhetslogiken? Hur fungerar det?

/Peter Tallungs

Nästa artikel i serien publicerar vi torsdag 16 juni. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Informationsmodellering: Om namngivning

Hur ska vi namnge alla de element i en informationsmodell som representerar verksamhetsbegrepp?

När vi tar fram en informationsmodell för en verksamhet eller en tjänst behöver vi besluta om namn för många olika saker. Det är inte bara entiteter, attribut och relationer som ska han namn utan också de specifika attributvärdena i det fall de utgör ett bestämt värdeförråd för något attribut. Alla dessa är verksamhetsbegrepp och bör ges korrekta och tydliga namn. Vad ska vi tänka på då? Vad är ett bra namn? Och hur gör vi med de namn som redan är etablerade på olika sätt i verksamheten, men kanske inte så lämpliga alla gånger?

Begrepp har namn och definition

Varje element i en informationsmodell, vare sig det är en entitet, ett attribut, en relation eller ett visst attributvärde, representerar en företeelse för vilket vi behöver ett namn.

Ibland handlar det om en helt ny företeelse i denna verksamhet men oftast om något som redan finns. Ett begrepp har två viktiga aspekter som bägge behöver uttryckas i naturligt språk. Dels behöver vi ta fram en korrekt och tydlig definition för att ringa in betydelsen, och dels behöver vi ett bra och tydligt namn.

Det kan till exempel vara att vi erbjuder våra kunder olika varor eller tjänster. Namnet vi bestämmer blir kanske ”Produkt”, och definitionen blir ”Det vi erbjuder våra kunder”.

Märk att det inte är själva namnet ”Produkt” som är begreppet i fråga utan det som namnet och definitionen står för. Namnet ”Produkt” är som ett handtag, en symbol eller ett tecken med vilket vi kan framkalla begreppet i våra hjärnor.

Om synonymer

Vi kan använda ett annat namn för samma begrepp (”Produkt”). Vi kan till exempel säga ”Vara”, ”Artikel” eller uttrycka oss på engelska och säga ”Product”, och ändå mena samma begrepp. Det kallas synonymer när ett och samma begrepp har flera namn. Det kan också finnas homonymer. Det är att ett och samma namn har flera betydelser.  

Vad är ett bra namn?

Ett bra namn ska vara korrekt, det vill säga så tydligt som möjligt peka på betydelsen hos det begrepp man vill använda namnet för. På sätt och vis fungerar det då som en liten definition i sig. Idealet är att man direkt förstår vad som menas och vad som inte menas. Åtminstone om man har lämplig förförståelse, som en allmän kunnighet om området i fråga. Namnet får inte ha en för bred betydelse och inte heller för snäv.

Vikten av bra namn

När vi sätter namn på detta sätt bygger vi de facto verksamhetens språk. Det är svårt att tänka sig en mer central och ansvarsfull uppgift som vi som modellerar kan ha. Med en korrekt och tydlig terminologi blir all kommunikation tydligare, i varje interaktion och integration. Risken för oklarhet och missförstånd minskar i varje punkt.

Men det finns också en annan minst lika tung aspekt som man kanske inte alltid tänker på. Vi använder språk inte bara för att kommunicera utan även för att tänka. Med en rik och tydlig vokabulär kan vi tänka klarare, både som individer och som grupp.

Råd för namn i informationsmodeller

Här följer ett antal saker att tänka på då vi bestämmer namn:

Förkorta inte

Jag anser att man i det längsta bör undvika förkortningar i de namn man sätter. Dels ökar det risken för misstolkning, och dels blir det en extra börda att hålla reda på alla förkortningar. Ty vi vill ju vara konsekventa så en term alltid förkortas på samma sätt överallt. Undantaget är några få mycket allmänna och etablerade förkortningar som ”SEK”, ”kg” etcetera.

Låt namnet uttrycka den fulla betydelsen

Om ett attribut heter ”Vikt” kan det förr eller senare bli osäkert i vilken viktenhet som avses.
Ändra till ”Vikt – kg”.

Använd verksamhetens språk

Det vill säga svenska i helsvenska verksamheter och engelska i verksamheter som ser sig som mer internationella. Det är ju verksamhetens språk vi normerar, inget annat.

Inom it-utveckling har det vuxit fram en informell standard att skriva namnen på programkonstrukter som moduler, klasser, metoder och variabler med mera samt även kommentarer på engelska. Därför tror ibland it-utvecklare att man ska skriva även verksamhetsbegrepp på engelska, även i det fall där verksamhetsspråket är svenska. Eftersom man vill vara konsekvent händer det också att engelskan fortplantar sig till andra sammanhang som rapporter med mera.

Därför ser man ibland amatörmässiga och ofta helt missvisande försök till engelsk översättning av svenska facktermer.

Jag menar att verksamhetstermer alltid ska vara på verksamhetens språk och det bör vara konsekvent överallt. Alltså även i programkod, databaser och filer, som ju är en integrerad del av verksamheten. 

Använd naturligt språk

Det innebär till exempel att man använder både versaler och gemener samt blanksteg.

Det förekommer annars att man i it-funktioner är påverkad av det skrivsätt som blivit standard i programkod på grund av att man där är begränsad till sammanskrivning av ord, så kallad ”Camel Casing”. Man skriver ”numberOfPieces” i stället för ”Number of pieces”. Men det finns alltså ingen anledning att tillämpa det skrivsättet utanför programkod.

Hur gör vi med redan etablerade men dåliga namn?

Det händer ofta att man sedan tidigare har namn i databaser och i system som är felaktiga och missvisande. Då kan det kännas som att vi i konsekvensens namn behöver fortsätta att använda de namnen. Namn har en tendens att bita sig fast väldigt hårt.

Men en dålig terminologi hämmar en verksamhets möjligheter framgent. Vår hållning måste vara att vi tar språk på allvar och att vi tar vårt ansvar. Vi kan inte bara fortsätta att propagera fel bara för att de en gång har uppstått. Vi behöver rätta till felen, även om det känns jobbigt för stunden. Vi behöver ju kontinuerligt vårda och utveckla verksamhetens terminologi.

Men om vi bara byter en term mot en annan, vet ingen vad vi menar med den nya termen. Förvirringen blir stor, man kanske tror att det är ett nytt begrepp, och inte ett nytt namn på ett befintligt begrepp.

Vi behöver hantera detta på ett ansvarsfullt sätt, det vill säga rätta till felaktigheter utan att ändringen skapar onödig förvirring. Det går till så här: I informationsmodellen anger vi det namn vi gemensamt kommit fram till är bäst, utan hänsyn till de misstag som har gjorts tidigare. Samtidigt anger vi i informationsmodellen det gamla etablerade namnet som en synonym som förekommer i verksamheten.

På så sätt får vi en spårbarhet från den äldre termen till den nyare. Våra informationsmodeller blir på så sätt på samma gång deskriptiv (beskriver befintligt språkbruk i verksamhet och it-system) och normerande (beskriver vad vi kommit fram till att det korrekta språket bör vara).

Exempel

Jag vill här visa exempel på hur det kan se ut i en informationsmodell. Detta är ett utsnitt från ett ER-diagram som visar en entitet med många attribut. I det följande beskriver jag de olika delarna av diagrammet.

  • Entitetens namn: ”Företagskonkurs – Statushändelse”
    Fetstil för att lyfta fram namnet, tydligt utskrivet och med versaler och gemener. Namnet är valt för att så tydligt som möjligt förmedla vad en förekomst av entiteten står för.
  • Källa för informationen: ”BLV (Daglig avisering via Bisnode)”
    Anger källan för informationen (BLV står för Bolagsverket). I detta fall hade vi många olika informationskällor och det var viktigt att lyfta fram dessa, därför rött typsnitt.
  • Entitetens definition: ”Händelsen att en företagskonkurs fått en ny status”.
    Försöker ge en så bra definition som möjligt för en förekomst av entiteten. Mörkgrått typsnitt för att tona ner uppgiften i förhållande till entitetens namn.
  • Grupprubriker för attribut: ”Identitet”, ”Typ av statushändelse” etc.
    Vi har strävat efter att ordna (sortera och gruppera) attributen i en ordning som känns naturlig och meningsfull. Detta är ett enkelt grepp för att öka modellens läsbarhet och begriplighet. Grupprubrikerna är mörkblå för att skilja ut dem från attributnamnen.
  • Attributnamn
    Vi har valt namn som försöker att ge en fullständig och tydlig betydelse.Logisk datatyp är med på många ställen som suffix. Vi har inte varit rädda för att skriva ut även långa namn och namn i flera led då det ökat tydligheten.
  • Teknisk datatyp och fältlängd: ”chr 1”, ”int”, ”dat” ”dat tid” etc.
    Skrivet i blått. Viktigt för att tolka data rätt.
  • Markering för obligatoriska attribut: ”obl”
    Behövs också för att tolka data rätt.
  • Fysiska fältnamn: ”PRIMARYKEY” ”KODFORDOMSTOLSOMUPPHAVTKONK” etc.
    Detta är vad attributen i fråga råkar heta i it-systemet, och som vi idag inte kan ändra. Detta är en typ av synonymer. Vi har använt ett grått typsnitt för att tona ner dessa i förhållande till de normerande attributnamnen.Det är viktigt att ha med fysiska namn för att få en spårbarhet till fysiskt data. Om vi inte har med dessa så blir det som att vår modell ”hänger i luften” utan koppling till en fysisk verklighet.

Användning av namnen i informationsmodellen

I de flesta sammanhang jag jobbat har vi på detta sätt använt informationsmodellen som en normering av den gemensamma terminologin i hela verksamheten. De namn vi satt är de som vi vill ska användas genomgående, som verksamhetens gemensamma språk. Det kommer dock att finnas synonymer alltjämt. Man kan inte bygga om alla rapporter och system bara för att vi har infört normerade begrepp.

Vi dokumenterar alla synonymer vi stöter på och i vilket sammanhang de förekommer. Men i allt nytt som görs kommer denna nya standardiserade terminologi att användas.

Namn i programkod, databaser och filer

Det är viktigt att detta normerade språk används i alla sammanhang. Många tror att man i programkod och liknande kan ha ”tekniska namn” som är annorlunda. Det är inte bra. Det ökar friktionen i kommunikationen. Jag menar att det är ett arv från den tiden då namn behövde vara korta och endast i versaler i programkod och databaser, av tekniska skäl. Så är inte fallet längre, i något sammanhang tror jag. Det man kan behöva göra det är en viss transkribering av namnen för de tekniska sammanhang där man inte har samma teckenuppsättning. Jag brukar då göra den transkriberingen redan i informationsmodellens textdel. 

Transkriberingsmetod

Den transkriberingsmetod vi då väljer bör vara den som gör minsta våld på namnen och har störst läsbarhet. Den metod vi har valt ofta är följande:

  • Ersätt Å, Ä med A, liksom å och ä med a.
  • Ersätt Ö med O, liksom ö med o
  • Ersätt blanksteg med understreck ”_”
  • Ersätt bindestreck med understreck ”_”  

”Konkurs avslutad – datum” blir då ”Konkurs_avslutad_datum”

Denna metod har en tradition inom databasdesign, vilket är en fördel.

Det finns dock en annan transkriberingsmetod som kommer från programvaruutveckling. Den kallas för ”Camel casing” eller mer anekdotiskt för ”Hungarian C”. Den består i att man använder versaler endast för att avdela mellan ord.

”Konkurs avslutad – datum” blir då ”konkursAvslutadDatum”.

Jag menar att den första metoden är att föredra och detta av tre skäl:

  1. Metoden gör inte onödigt våld på namnet. Läsbarheten är bästa möjliga. 
  2. Versalerna har samma funktion som före transkriberingen.
  3. Metoden har en tradition inom databasutveckling vilket ligger kulturellt och historiskt närmare informations- och databehandling än programvaruutveckling.  

Hur gör ni?

Vad sägs om detta? Hur gör ni i er verksamhet?

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 9 juni. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

17 missuppfattningar om arbetet med verksamhetens begrepp

Som informationsarkitekter behöver vi arbeta med verksamhetens begrepp, både benämningar och definitioner. Men vi har stött på många missuppfattningar om hur det ska gå till. Här är min favoritlista.

Missuppfattning 1: Namn och definitioner är inte så viktiga

Det är inte alla som förstår att det är viktigt för en verksamhet hur man arbetar med det gemensamma språket. Hur centralt det är att man har bra gemensamma begrepp med korrekta och tydliga namn, och bra definitioner på saker och ting. Inte bara på företeelser (entiteter) utan också på egenskaper (attribut), relationer, möjliga egenskapsvärden, dataelement med mera.

Ofta har man inte när man definierat en verksamhetsfunktion eller informationsmängd gjort ett aktivt valt namn utan bara accepterat vad det råkar heta i ett it-system. Eller så har någon bestämt att man ska ha ett namn som är på modet och låter tjusig, men som inte säger vad det är. Det är även mycket vanligt att man tagit en mycket allmän term och låst den i en specifik betydelse.

Jag har ibland sett att arkitekter har tyckt att detta varit okej, och inte tyckt det varit viktigt. Det enda man krävt är att de namn som satts ska användas konsekvent.

Allt inte se värdet i bra benämningar och definitioner underminerar vår gemensamma förståelse och förstör vårt verksamhetspråk i stället för att vårda och utveckla förståelse och språk. Jag kan nästan inte tänka mig något effektivare sätt att begränsa en verksamhet i det långa loppet. Ty utan ett effektivt gemensamt språk kommer vi hela tiden att prata förbi varandra och sent bli varse att vi inte har menat samma saker.    

För att läsa mer om vikten av namn och definitioner, se tidigare artikeln ”Om det viktigaste du gör som informationsarkitekt – Arbetet med verksamhetens begrepp och språk, 2022-05-12”

Missuppfattning 2: Namn och definitioner ingår inte i informationsmodellering

Det händer att de som informationsmodellerar inte förstår att en kärna i informationsmodellering är verksamhetens begrepp, och att vi därför hela tiden måste arbeta med namn och definitioner. 

Det är inte så konstigt att den uppfattningen florerar när arbetet med definitioner och benämningar sällan eller aldrig ens berörs på kurser eller i böcker om informationsmodellering.

Missuppfattning 3: Namn och definitioner är något vi bör överlåta åt verksamhetsexperter

Många gånger har de som tagit fram informationsmodeller låtit folk i verksamheten ta fram namn och definitioner. Man har tyckt att det är deras jobb. Det fungerar inte. De har sällan den kompetensen.

Verksamhetskunniga av olika slag behöver naturligtvis vara djupt involverade i arbetet, men det krävs en särskild kompetens, erfarenhet och överblick för att leda och facilitera arbetet med terminologin. Det är svårt att tänka sig att man kan jobba med informationsmodellering på ett bra sätt utan att i grunden jobba med begrepp och termer.

För att läsa mer om hur man inte ska göra, se tidigare artikeln ”Historier från dataträsket 1 – Hur jag lärde mig att verksamhetsexperter inte kan allt, 2022-03-31”

Missuppfattning 4: Det spelar inte någon roll vilka namn som väljs, bara de är unika

Ofta när man överlåtit till verksamhetsfolk att sätta namn har man inte lagt någon som helst värdering på vilka namn som valts. Vilket namn som helst duger, bara det sedan används konsekvent. Det är ett sätt att helt missförstå betydelsen av namn, att bara se dessa som unika identifierare utan att de behöver förmedla någon betydelse.

Vilka namn vi väljer på saker och ting styr i hög grad hur vi kan tänka om dessa ting. Därför är det viktigt att noga överväga vilka namn man väljer.

Missuppfattning 5: Vi har en ordlista (glossary). Det är platsen för namn och definitioner

Många verksamheter nöjer sig med en ordlista. Det är bättre än inget alls. Men det finns svagheter med detta jämfört med att använda en informationsmodell.

  1. En ordlista har oftast bara nominella definitioner
    Den ger endast ordförklaring. Det vill säga att den förutsätter att man redan fullt och fast förstår den företeelse termen betecknar. Jämför med ett lexikon som även förklarar företeelsen i sig. Vi behöver mer än ordförklaringar. Vi behöver mer som ett lexikon, som vi kan slå upp i för att förstå företeelserna. 
     
  2. En ordlista har ingen annan struktur än en alfabetisk ordning
    Företeelser behöver förstås och förklaras i samband med andra närliggande företeelser. Det är den grundläggande idén inom begreppsanalys. Därför är en tematisk ordning mycket effektivare än en alfabetisk ordning, när man verkligen vill dokumentera något. En informationsmodell kan (och bör) byggas upp och struktureras ämnesområde för ämnesområde. Allt om och runt ”Kund” beskrivs tillsammans, allt om ”Produkt” beskrivs tillsammans. Varje ämnesområde beskrivs utförligt både med grafik och text.

    Sedan är det förstås lämpligt att ha ett alfabetiskt index för att snabbt hitta förklaringen på en term. Indexet leder en till den plats där termen beskrivs, i sitt sammanhang.
  3. Arbetet med att informationsmodellera kan inte isoleras från arbetet med att arbeta med termer och definitioner – om bägge ska göras bra
    De bägge uppgifterna behöver ske helt integrerat, och är därmed i praktiken ett och samma arbete.

    Därför bör informationsmodellen vara mycket mer än en modell över informationen. Den beskriver de facto allt som verksamheten hanterar, inklusive språket för detta, verksamhetsreglerna och informationen som behövs för att representera detta.

    Allt detta gör att en bra informationsmodell, uppbyggd tematiskt ämnesområde för ämnesområde, är den bästa beskrivningen av det som verksamheten hanterar och hela terminologin för detta. Och jag vill gå ännu längre. En sådan informationsmodell är, rätt utformad, den bästa arbetsplattformen för att kontinuerligt och hållbart vårda och utveckla den gemensamma förståelsen och terminologin.

    Men detta förutsätter att informationsmodellen är mer än ett diagram. Vi behöver även strukturerad text som en integrerad del av modellen; för definitioner, beskrivningar, regler, noteringar med mera.

Missuppfattning 6: Namn och definitioner är redan bestämda, så vi kan inte röra dem

Så är det ofta och det är så klart ett hinder. Men om man alltför starkt värnar om staus quo riskerar man att låsa fast sin organisation i en dålig och missledande terminologi som skadar verksamheten permanent. Det är viktigt att förstå att det inte bara är verksamheten i sig som behöver utvecklas kontinuerligt utan även språket om verksamheten.

Sättet att komma runt denna låsning är att inte kräva konsistens som första princip, det vill säga att allt måste heta lika överallt utan undantag. Ty detta är säkraste sättet att låsa en verksamhet i en limbo. Vi behöver alltid hantera synonymer. Vi kan således förorda ett nytt bättre namn som norm i stället för ett som inte fungerar, men samtidigt hantera att det gamla ingrodda namnet vilket får leva kvar som en synonym.

Missuppfattning 7: Namn och definitioner ska vi sätta en gång för alla. Sedan får de inte röras, utom i mycket speciella fall

Liknande problem som föregående. Vi måste i vårt arbete hantera att saker utvecklas, att saker ändras i sig själva eller att vi når en bättre förståelse så småningom. Allt ska kunna ändras, och det måste vi ha arbetssätt och mekanismer för att hantera på ett kontrollerat sätt.

Det är klart att det kan vara frustrerande att behöva ändra saker som redan är bestämda. Men motsatsen är värre, att vara låst vid tidigare beslut och vara tvungen att bara fortsätta gräva ner sig mer och mer i ett dåligt spår. Utveckling är och måste vara agil och iterativ.

Vi hanterar ändringar genom att versionshantera modeller. På så sätt kan man ändra en modell utan att allt som är baserat på denna behöver ändras. I längden vill man ju förmodligen anpassa implementationer till den senaste versionen av modellen, men man har sålunda en frihet att bestämma när och om man ska anpassa. I en föränderlig värld kan inte allt vara helt synkat i varje läge. Vi behöver kunna hantera detta på ett bra sätt.

Missuppfattning 8: Namn och definitioner ska fastställas av en nämnd

Det är ett vanligt förfarande att ha en nämnd som ska godkänna och besluta om namnförslag, men i min mening är detta dysfunktionellt. Att någon gör jobbet men andra bestämmer är en förlegad tayloristisk syn på arbetets organisation som vi bör lämna. (Taylorismen bygger på att vissa personer har förståelse och andra personer ska bara utföra sina uppgifter mekaniskt utan att ifrågasätta.) Det är de som hela tiden jobbar med benämningar och betydelser som har bäst förutsättningar att väga in olika synpunkter och att besluta om ändringar. Det vill säga vi som modellerar, vi som har eller bör ha kunskaper om hur man jobbar med begrepp och språk, vi som dagligen funderar och diskuterar med olika parter. Vi behöver löpande tillsammans med de som är närmast involverade i varje område besluta. Och även kunna ändra oss när vi kommer till bättre insikt. Det är inte sannolikt att en nämnd har bättre förutsättningar för detta än vad vi har.

Sedan är det förstås så att vi måste ha byggt upp ett förtroende för att ha detta viktiga ansvar. Ett förtroende som kan brytas om vi inte sköter det bra.

Missuppfattning 9: Sammanblandning av definition och beskrivning

Jag ser ofta att de som försöker skriva definitioner i stället skriver beskrivningar av olika slag, och inte riktiga definitioner. En definition är en ordföljd man kan sätta i stället för namnet. Beskrivningar behövs ofta också, men det är något som kompletterar en definition, inte ersätter.

Missuppfattning 10: Vi behöver bara bry oss om ”tekniska” namn

På it-sidan finns det ofta en föreställning om att man på insidan av en applikation eller en databas har namn som bara har en teknisk funktion. It-utvecklare tycker att vad samma företeelser heter i användargränssnitt och rapporter, där verksamhetsfolk möter dem, är en annan sak. Man vill inte skapa ett beroende och man tycker att man alltid kan översätta fram och tillbaka. Detta är en grundläggande missuppfattning som skapar en effektiv kommunikationsbarriär mellan verksamhet och it.

Verksamhet och it bör sträva efter att ha samma namngivning så långt det går och så långt vi gemensamt kan styra. Modeller och språk är ju till för att vi ska ha en gemensam förståelse och en effektiv kommunikation, tvärs över gränserna. Om vi vid en integration översätter bara en term kan det tyckas som en liten sak, det ökar friktionen i kommunikationen men obetydligt. Men när vi gör det med tusentals termer ökar friktionen i kommunikationen plötsligt dramatiskt. Och allt saktas ner.

I vissa sammanhang behöver vi korta namnen, för att tekniska miljöer inte klarar å, ä, ö eller skiljetecken. Vi bör då ha tydliga regler för hur man transkriberar.

Missuppfattning 11: Vi har ett affärssystem som har en fastställd terminologi. Då är det redan klart

Att inte själv äga och kontrollera sin terminologi är att släppa kontrollen över en central aspekt av sin verksamhet. Tro inte på leverantörer av standardsystem som säljer in dessa som att ni köper in er i en etablerad branschstandard som är ”best practice”. Något hyfsat heltäckande sådan finns inte, utanför väldigt smala områden. Har vi standardsystem måste vi ändå ha egna modeller och en egen terminologi.

Missuppfattning 12: Vi har en industrimodell som ger oss en terminologi som också är en standard för en hel bransch

Detta är en vanlig missuppfattning. Det finns industrimodeller som säljs in med anspråk på att kunna användas internt, med en lättare anpassning. Men antingen är de begränsade till enbart kommunikationen mellan parter inom ett smalt ämnesområde, ibland inom en specifik bransch, ibland tvärs över flera branscher. Eller så är de bredare, men då mer av bygglådor som man kan använda som inspiration för att bygga sin egen terminologi. Vilket man inte kan göra om man inte först skaffar sig dökoll på sin egen verksamhet i alla dess detaljer och egenheter, det vill säga att man modellerar.

Egenheterna i verksamheten kan vara motiverade eller onödiga. I vilket fall måste vi förstå och hantera dem. De onödiga kan vi kanske avveckla så småningom, men inte förrän vi fullt ut förstår dem, och då verkligen förstår att de är onödiga och hur vi ska kunna avveckla dem. Inget av detta kan en industrimodell hjälpa oss med.

Du kan aldrig köpa en färdig modell, ty den är värdelös om den inte representerar er gemensamma förståelse. Och en gemensam förståelse får vi genom att själva modellera. Det är alltså vägen som är mödan värd. Modellen är bara värd något så länge den representerar vår gemensamma förståelse. Gemensam förståelse kan inte köpas.

Flera svenska banker och försäkringsbolag har köpt in industrimodeller och försökt implementera dem. Några har gett upp efter ett tag. Andra har framhärdat och har på så sätt skadat sitt språk och sina möjligheter att verkligen bygga en gemensam förståelse.

En del hävdar att man kan använda en industrimodell som en inspiration till sin egen modell. Det är sant, men i så fall handlar det inte om att implementera industrimodellen. Vi kan och bör alltid inspireras av modellmönster från olika källor. Jag tycker inte att de industrimodeller jag sett har varit särskilt bra källor för detta, men om någon är av annan åsikt så låt gå för det. Men det handlar då inte alls om att implementera industrimodellen i den egna verksamheten. Ty att inspireras av något i en standard är inte samma som att implementera standarden.

För att läsa mer om mina tankar kring industrimodeller se tidigare artikeln ”Varför en industrimodell är en dålig idé!, 2021-03-25

Missuppfattning 13: Det är viktigt att samma namn används överallt. Det får inte förekomma avvikande benämningar

Vi behöver alltid hantera synonymer, vanligen många sådana. Varje system, varje integration, varje fil brukar ha sina egna benämningar. Ibland är de ganska korrekta, ibland är de djupt missvisande. Ofta har någon programmerare varit tvingad att på kort tid och utan hjälp hitta på ett namn och det har kanske inte blivit så bra.

I vilket fall måste vi dokumentera dessa synonymer. Vad de heter i ett visst sammanhang. De dåliga benämningarna kan vi kanske med tiden arbeta bort. Men vi kan inte veta när det kan ske. I vilket fall måste vi dokumentera och hålla koll på dessa.

Det finns i branschen ofta en dröm om enhetlighet. Men säg att vi i en rosa framtid verkligen lyckats etablera konsekventa benämningar överallt, att vi har fått en helt konsekvent verksamhet tvärs igenom. Då köper vårt företag upp ett annat och slår ihop dessa. Återigen har vi inkonsistens. Dessutom behöver vi ju alltid interagera med parter utom vår kontroll, såsom partners, leverantörer, outsorcade funktioner, myndigheter, branschnätverk med mera. Så drömmen om en total enighet är fåfäng. Vi kommer alltid att behöva hantera synonymer, homonymer, och inte bara det utan även olika strukturer som behöver samverka. Speciellt i en föränderlig värld där utveckling sker kontinuerligt.

För att läsa mer om mina tankar kring namnsättning, se tidigare artikeln ”Den omöjliga drömmen om den allomspännande informationsmodellen, 2021-11-25”

Missuppfattning 14: Namn ska vara korta

Förr var det viktigt att namn var korta, av tekniska skäl. Vanliga databaser klarade inte så många tecken. Idag har det ingen praktisk betydelse. Det viktiga är att namnet är användbart i så många sammanhang som möjligt, vilket innebär korrekt och så begripligt som möjligt. Med detta sagt är det ju naturligtvis så att om vi har två annars likvärdiga alternativ att välja mellan så är det kortare att föredra. Men endast då.

Fast vi kan behöva förkortningar också, för användning i vissa sammanhang, till exempel för att rymmas som rubriker i smala i rapportkolumner.

Om vi i det längsta undviker förkortningar i övrigt, slipper vi ta fram och underhålla standarder för hur vi förkortar på ett gemensamt sätt.

Missuppfattning 15: Namn ska vara ett ord

Namn behöver ofta vara två eller flera ord i följd för att bli korrekta och tydliga. Det ska inte vara något problem. Ibland ser man att man skriver ihop namn enligt standarden ”camel casing” som är vanlig i programmeringsspråk. Exempel: ”AnsokanDatum”, ”ProductStatus”. Det är varken korrekt svenska eller engelska, utan är något som smittat av sig från programmeringsspråk.

Missuppfattning 16: Vi ska ha engelska namn internt i alla system även om organisationen är svensk och verksamhetsspråket är svenska

Programmerare använder ofta engelska internt i programkoden, filer, databaser och api:er, både för att namnge tekniska strukturer och för att kommentera koden. Ibland ser man hur detta sprider sig till hur man namnger verksamhetstermerna i programkod, och även i tjänster och liknande.

Detta får till resultat i helsvenska verksamheter att vi får en gemensam överenskommen och genomtänkt terminologi på verksamhetens språk, det vill säga svenska. Och att vi så snart vi tittar i programkod, tjänstebeskrivningar och filer hittar en helt annan terminologi. Ibland med en blandning av amerikansk och brittisk engelska, ofta med amatörmässigt översatta termer. Till exempel försäkringsverksamhet skiljer sig ofta i terminologi mellan europeisk och amerikansk.

Eftersom programtekniska termer namnges på engelska, tror man att man är konsekvent då man även namnger verksamhetstermer i programkoden på engelska. Men i själva verket har man offrat en viktig konsekvens, den mellan det gemensamma verksamhetsspråket utanför programvaran och det inuti densamma. Man tror sig ha fått en konsekvens, men endast där den inte har något värde, endast i just den specifika programkoden, och där mellan de mer programtekniska termerna och verksamhetstermerna.

Missuppfattning 17: Arbetet med begrepp är något för professionella terminologer, inget vi informationsmodellerare ska syssla med

Det är sant att det är en styrka att ha tillgång till en terminolog och att samarbeta med en sådan runt benämningar och definitioner. Men det betyder inte att jag som informationsmodellerare kan släppa det hela. Vi behöver jobba ihop, nära och interaktivt. Oftast har jag inte tillgång till en terminolog. Då måste jag själv fungera som en sådan. I vilket fall som helst måste jag vara lite av terminolog själv.

Håller du med?

Din favoritlista med missuppfattningar ser kanske annorlunda ut. Du kanske vill lägga till någon eller har en annan uppfattning. Låt höra! Om vi byter erfarenheter och åsikter så blir vi tvungna att reflektera. Då utvecklas vi.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 2 juni. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Vad är en bra definition?

Skriva definitioner är en viktig del av vårt arbete när vi informationsmodellerar. Men det finns olika slags definitioner, och alla är inte lika bra. Vad vi ska söka efter när vi letar efter en bra definition? Och vad är en bra definition egentligen?

Nominell definition och riktig definition

När man försöker hitta en definition så bör man undvika det som kallas för nominell definition. En nominell definition är ingen riktig definition utan ersätter bara ett ord med ett annat ord eller ger en beskrivning av hur något ter sig utan att egentligen förklara innebörden för oss.

  • Exempel på en nominell definition: ”Åska är när det dundrar från molnen.”
  • Exempel på en riktig definition: ”Åska är elektriska urladdningar i jordens atmosfär som yttrar sig i ett uppflammande av ljus och ett skarpt eller mullrande ljud.”

Nominella definitioner är av begränsat värde och ska om möjligt undvikas.  

Typer av definitioner

Vi kan dela in definitioner i ett stort antal typer, alla med fördelar och nackdelar. En del typer är riktiga definitioner medan andra endast är nominella.

Men vi kan inte alltid vara kräsna. Beroende på vilket begrepp vi definierar kan vi inte alltid hitta en riktig definition utan vi får ta det vi kan komma på, och som fungerar bäst.

Det är då bra att känna till vilka typer som kan finnas och reflektera över deras respektive styrkor och brister, och därmed grader av användbarhet.

Typ av definitionKommentar
Essentiell definition Man finner först det generiska begreppet, sedan identifierar man hur det specifika begreppet skiljer sig från det generiska. Exempel: ”En triangel är en plan figur innesluten av tre räta linjer.” Detta är den klassiska perfekta definitionen, ända sedan Aristoteles.Betraktad som den ideala formen, både i den klassiska logiken och av oss idag. Fördelen är att definitionen bygger på hur vi förstår begrepp, det vill säga att vi förstår ett begrepp i relation till andra begrepp. Nackdelen är att det fungerar endast för företeelser som kan ordnas i någon form av hierarkier.
Distinkt definition Man bestämmer föremålets unika egenskaper. Exempel: Piracy consists of any of the following acts: a) any illegal acts of violence or detention, or any act of depredation, committed for private ends by the crew or a private aircraft, and directed…. b) any act of inciting or of intentionally facilitating an act described in sub-paragraph a).Viktigt att täcka in så mycket som möjligt av de egenskaper som är viktiga både nu och vad som kan tänkas för framtiden.
Kausal definition – ändamål Exempel:”rapport till Finansinspektionen med sammanställning av försäkringspremier för året.”Kan vara användbart som en del av en beskrivning. Bra att veta syftet med något.
Kausal definition – orsak Exempel:”tabell byggd i samband med DOB-projektet”Kan vara användbart som en del av en beskrivning. Bra att veta historien bakom något. Kan fungera som startpunkt i dokumentationsarbetet.
Genetisk definition Exempel: ”balans beräknad vid midnatt, varje bankdag”Är åtminstone användbar information. Bra att veta när, hur och var något skapas. Kan vara en startpunkt i dokumentationsarbetet.
Slumpmässig definition Bygger på egenskap som inte är företeelsens essentiella natur. Exempel:”Medarbetare på företaget är kvinna som..”Inte en riktig definition men kan ändå vara användbart.  
Ostensiv definition Man visar på exempel. Exempel:”Storkund är kund som Ericsson, H&M eller Statoil”Ofta användbart. Även illustration eller bild fungerar.
Stipulativ definition Man ger en term en helt ny betydelse. Exempel:”med köp menar vi alla typer av betaltransaktioner”En typ av nominell definition. Viktigt att vara tydlig med termens vanliga betydelse.
Legislativ definition
Specialfall av stipulativ definition. Vi skapar ett nytt begrepp. Exempel:”Customer Lifetime Value is the expected revenue for a Customer during its lifetime”
Inte en typ av nominell definition. Detta är vanligt i all slags modellering.

Termer som är omöjliga eller nästan omöjliga att definiera

Många av de vanligaste begreppen vi rör oss med är notoriskt svåra att ge en definition. Exempel: ”kvantitet”, ”kvalitet”, ”relation”, ”plats”, ”tid”, ”tillstånd”, ”aktivitet”. De karakteriseras av att de är grundläggande och mycket vanliga och har många synonymer. Men dessa behöver vi vanligen inte heller definiera. Vi kan förutsätta att den exakta betydelsen framgår av sammanhanget.

Vad vi önskar av en definition

Vad ska vi försöka uppnå med en definition? Det är inte så lätt alla gånger, men detta är i varje fall vad vi eftersöker. Ofta får vi göra avkall på dessa krav.

  • Ska vara en riktig definition, inte en nominell
    Ordböcker har ofta nominella definitioner, men en informationsmodell är mer än en ordbok, det är mer som en lärobok eller ett lexikon.
  • Ska vara komplett
    En bra test är att se om definitionen kan sättas i stället för termen som definieras.
  • Ska inte vara för smal, det vill säga den ska täcka allt som termen kan stå för
    Detta är mer ett mål än ett absolut krav. Minsta krav är egentligen bara att när en definition publiceras ska den vara tillräckligt bra för att användas, och inte skapa problem.
  • Ska inte vara för bred, det vill säga den ska inte täcka mer än det termen kan stå för
    Mycket generella definitioner är lätta att skriva, men inte särskilt hjälpsamma, och kan förvirra.
  • Ska vara korrekt
  • Ska kunna klargöra en tvetydig term
    Därför kan det vara bra att ha med vilken betydelse termen inte har, det vill säga en eller flera homonymer.
  • Ska inte vara dunkel och otydlig i onödan
    Ska kunna förstås lätt av person med rimlig kunskap i sammanhanget. Man kan i vissa sammanhang ha två definitioner, både en enkel att förstå och en mer precis. (Det väcker frågan vem vi skriver för: Mottagarna kommer mest troligt att vara kunskapsarbetarna i organisationen. Där måste vi anta en viss bakgrundskunskap.)
  • Ska inte vara tautologisk, eller med synonym
    Exempel: ”En människa är en medlem av arten Homo sapiens”. Detta är ett vanligt fel. Den definitionen ger ingen information alls.
  • Ska inte vara cirkulär
    Exempel: Dygn är en period på 24 timmar”.”Timme är ett 24-dels dygn”.
  • Ska inte vara negativt formulerad (om den kan vara positiv)
    En negativ formulering är ofta svårare att förstå.
  • Ska markera tvetydighet och oklarhet explicit
    Verksamhetstermer kan ofta vara tvetydiga, eller oklara, för oss. Det är då viktigt att vi skriver ner att vi är osäkra på vad vi i dagsläget inte vet.
  • Ska inte räkna upp förekomster
    Ofta har man räknat upp förekomster utan att de har något mer gemensamt än verksamhetens avsikt med dem. Det är då endast möjligt att fånga den avsikten.

Vad som är viktigt egentligen

Vi ska så klart sträva efter att skriva så bra definitioner som möjligt, och hela tiden träna på att bli bättre på detta. Men det viktiga när allt kommer till kritan är egentligen bara att definitionen är användbar, att det hjälper den som läser den att förstå vad termen står för.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 26 maj. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

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

Informationsmodellering handlar inte bara om data och information, utan också om att analysera, beskriva och normera verksamhetens begrepp och språk. Den viktigaste uppgiften vi har som informationsarkitekter, enligt mig. Ändå är det sällan eller aldrig den uppgiften beskrivs i litteraturen om informationsmodellering eller Data management.

Vikten av begrepp och språk.

Malcolm B. Chisholm är den ende inom Data/Information Management som jag vet har intresserat sig för hur vi arbetar med definitioner. År 2010 kom han ut med boken Definitions in Information Management. I förordet citerade han ett par kollegor:

”What do you mean by ____?

After close to 30 years in the consulting business, I think that is the most important single question one can ask during an engagement.

What I´m talking about, of course, is the art and science of clarifying communication through good definitions. And it isn´t just the end result that matters – the process of building definitions is as important as the destination. Along the way, you find out what you really think a term means, what they think it means, what the term might mean sometime in the future, and any number of other details that will surface and explain miscommunication. “

Alec Sharp, Claritec Inc

“Ambiguity is a kind of friction which limits the quality of our discourse, the utility of our data, and the reach of our understanding.

All progress in information management depends on our ability to identify its source and reduce it to its absolute minimum.

In this regard, no other effort pays more dividends that that of establishing good definitions.”

Suzanne Yoakum-Stover, Ph.D. Executive Director, Institute for Modern Intelligence

Jag kan instämma, med hela min erfarenhet. Det är mer regel än undantag i våra organisationer att dataelement är otydligt eller felaktigt namngivna, definierade och beskrivna. Ofta är de inkonsistent populerade, och misstolkas då de används. Detta beror till stor del på att man inte tagit fram och använt tydliga namn och definitioner.

Hur du väljer namn och definitioner har ofta mycket större betydelse för verksamheten än hur du strukturerar information. Namn och definitioner lever ofta kvar i decennier, vanligen längre än de system vi bygger.

Termer och begrepp är mycket viktigare än vi ofta föreställer oss. Vi bygger ett språk, och språket utgör inte bara kommunikationens grundvalar utan även tänkandets. Begreppen vi använder formar och begränsar hur vi kan tänka.

Varför är detta en uppgift för oss informationsarkitekter?

Är detta verkligen en uppgift för oss informationsarkitekter? Ska vi inte bara använda de benämningar och definitioner som verksamhetens sakkunniga ger oss?

Nej, så enkelt är det inte. När jag analyserar och beskriver de data och den information som förekommer, så handlar det inte bara om informationen i sig utan det som informationen står för. Det vill säga de företeelser som informationen handlar om, inklusive dessas egenskaper, relationer, regler med mera. Då hittar jag också namn som oftast är dåligt valda och missledande. Ofta har en och samma sak fått många olika namn när det transporteras genom verksamhetens många olika system, filer, rapporter, användargränssnitt och api:er. Många namn är sammanblandande och förvirrande. Ännu värre kan det vara med definitioner, om de ens finns. Ofta är de fel och missledande.

Då måste jag bestämma ett normerande namn och hitta en korrekt definition, samt hantera alla namn som förekommer som synonymer. Det är klart att jag gör det tillsammans med sakkunniga, men det är normalt jag som får använda mitt omdöme och min erfarenhet av namngivning och begreppsanalys för att komma fram till ett namn och definition som blir bra och verkligen fungerar.

Det är svårt att tänka sig att det skulle gå att arbeta med namn och definitioner utan att samtidigt jobba med företagets data. Därmed menar jag att arbetet med verksamhetens alla namn och definitioner i praktiken är sammanvävt med informationsarkitektens arbete med data och information.

Om vi skulle ha lyxen att i organisationen ha någon som är särskilt kunnig med och ansvarig för verksamhetens nomenklatur blir det ändå så att jag som informationsarkitekt måste jobba tillsammans med denne. Det data jag hittar ger input till vad vi behöver benämna. Det går därmed inte att säga att man först måste ha ordning på alla namn och begrepp, och först därefter kan informationsmodellera. Det är ett iterativt arbete med tät samverkan mellan arbetet med informationen och arbetet med språket.

Därmed utvecklar och underhåller vi verksamhetens terminologi.

Men konstigt nog behandlas inte detta viktiga område alls när man studerar vad som skrivits inom områdena informationsmodellering, informationsarkitektur och Data Management. Jag har kanske trettio böcker om informationsmodellering hemma, men jag har inte sett detta behandlas någonstans, vad jag kan minnas. Den internationella organisationen DAMAs referensverk om Data Management: DAMA-DMBOK går på 600 sidor igenom Data Managements alla delämnen. Men inget om namngivning, begrepp och definitioner.

Chisholms bok, som jag nämnt ovan, är det enda undantaget.  

Vad behöver definieras?   

Att jobba med namn och definitioner är förmodligen det viktigaste vi gör som informationsmodellerare.

Alla element i en informationsmodell behöver ha användbara namn, definitioner och beskrivningar. Det är en viktig del av det löpande arbetet för oss informationsarkitekter.

Med element i en informationsmodell menar vi inte bara entiteter utan även attribut, relationer, förekommande värden för attribut med uppräknade värdemängder samt hela ämnesområden.

Även dataelement i våra databaser, filer, tjänster, applikationer, formulär och rapporter behöver ha användbara namn, definitioner och beskrivningar.

Vad behöver vi ha definitioner till?

Vi behöver definitionerna för att förstå de verksamhetsbegrepp som representeras i data. Vi behöver definitioner för att härledda termer ska bli korrekta, och för att mappa och spåra data genom olika käll- och målsystem. Vi behöver definitioner för att jämföra datainnehåll med definitionen.

Vi behöver definitioner för att veta att vi verkligen pratar om samma saker i alla sammanhang. Särskilt viktigt är det i analyser och rapporter.

Det finns vissa situationer då man tydligare än annars lider av brister i definitioner: Till exempel källdataanalys i BI-projekt, dataanalys när system ska ersättas samt integrationsprojekt.   

Jag tror att många som läser detta känner igen sig. Men låt oss då göra något åt detta!

Hur behöver vi jobba med definitioner?

När jag handleder elever i informationsmodellering får jag ofta hjälpa dem att skriva definitioner. De flesta tror att de skriver definitioner men skriver i själva verket beskrivningar av olika slag. Vilket ofta också behövs, fast först och främst behöver vi bra definitioner. Men med några enkla råd blir de snabbt bättre.

Namn och definition är olika saker men följs åt i arbetsgången. När du har tagit fram eller ändrat en definition för något behöver du ofta ändra namnet för att det ska avspegla innebörden. Arbetet med namn och definitioner är inget som går att separera från det övriga modelleringsarbetet, utan är själva kärnan i det vi gör när vi modellerar. Så snart vi ritar en entitet och ger den attribut och relationer så behöver vi ta fram både namn och definition.

Till en början är både namn och definition på försök, de är tentativa. Med tiden arbetar vi om dem, i takt med att vår gemensamma förståelse utvecklas.

Ibland kör vi fast. Vi kan inte komma på hur vi ska definiera något, eller kanske hur vi ska benämna det. Men då hjälper det alltid att vi sover på saken. På något sätt arbetar då hjärnan omedvetet, och nästan utan undantag kommer nya friska idéer. Det är det vi kallar aha-upplevelser.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 19 maj. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Om begreppsmodellering

Begreppsmodellering är något man kan ta till för att få ordning på termer och begrepp inom ett område. En begreppsmodell är i sin grund något annat än en informationsmodell. Det finns dock samband, och i praktiken delvis överlappande syfte med dessa två typer av modeller. I denna artikel visar jag vad en begreppsmodell kan vara.

En begreppsmodell är inte en informationsmodell

En begreppsmodell kan till det yttre tyckas vara detsamma som en informationsmodell. Båda har boxar som står för olika begrepp och streck som står för relationer mellan begreppen. Men likheten är bedräglig. En renodlad begreppsmodell har ett annat syfte än en informationsmodell, och både boxarna och relationerna representerar något annat.

Följande tabell visar skillnaderna.

Syfte – analysera och beskriva:En box representerar:En relationslinje representerar:
Informations-modellden information som hanteras eller behöver hanteras och hur den kan struktureras. (Det innebär att informationsmodellen också beskriver det som informationen representerar, det vill säga de företeelser som verksamheten behöver hantera, inklusive dessas egenskaper och relationer.)(informationen om) en företeelse som har förekomster, det vill säga en klass av något. Exempel: Kund, Avtalett informationsmässigt samband. Exempel: Information om en kund refererar kundtyp, kundstatus, land etcetera
Begrepps-modellde begrepp som finns och ska förstås inom ett område.ett begrepp. (Vilket kan stå för en klass av något, men egentligen vilket begrepp som helst, till exempel: en viss förekomst av något, en egenskap, en relation eller ett visst värde, eller något helt annat som inte alls har någon representation i en informationsmodell) Exempel: Taxering, kvalitet, vinstsyfte, abstrakt, alienation, empiri, heliocentrisk världsbilden referens till ett annat begrepp som detta begrepp relaterar till i sin definition. Exempel: ”En kund är en organisation som vi erbjuder våra produkter”. (Här finns en begreppsmässig referens från begreppet ”kund” till begreppen ”organisation” och ”produkt”.)

Exempel på hur man kan begreppsmodellera

För att riktigt beskriva vad begreppsmodellering är, är det lämpligt att visa hur det kan gå till. Följande exempel använder Stanli-notation, vilket är en notation som är renodlad för begreppsmodellering. Den togs en gång fram av det svenska standardiseringsorganet Stanli och var från början avsett för analys och beskrivning av begrepp för geografisk information, men kan användas för alla slags begrepp.

Här exemplifierar jag modelleringsprocessen i tre steg. Exemplet handlar om de ordinationer en läkare kan ge en patient, och säg att vi behöver reda ut vilka olika begrepp som kan förekomma i det sammanhanget och vad de egentligen betyder Detta är en förenklad bild av modelleringsprocessen. I verkligheten är gången mycket mera iterativ.

Steg 1:    Ordna begrepp i begreppshierarkier som visa hur ett begrepp är en specialisering av ett annat begrepp

Man ordnar begrepp i begreppshierarkier.
Ett begrepp är ofta en specialisering av ett annat begrepp. Därför är begreppshierarkier ymnigt förekommande i begreppsmodeller.

Steg 2:    Beskriv övriga begreppsmässiga samband mellan begrepp

Begreppsmässiga samband är de referenser till andra begrepp som behövs för att definiera ett begrepp. Ofta är det de relationer som skiljer två begrepp som båda är specialiseringar av samma generella begrepp från varandra. I exemplet är det som skiljer en ordination från en generell ordination att den avser en specifik patient.

Steg 3:    Ta fram definitioner

Pilarna från ett begrepp är referenser till andra begrepp som behövs i definitionen.

Exempel på en färdig begreppsmodell


Här är ett exempel på en färdig begreppsmodell som visar några av de centrala begreppen i en biblioteksverksamhet. I Stanli-notation skriver man in definitionerna i begreppsboxarna. De blå boxarna representerar begrepp som man utgår från och använder i sina definitioner, och som man bedömer att man inte behöver definiera.  

När ska man begreppsmodellera?

Det är ett verktyg att ta till då man inte kan reda ut begrepp på ett annat sätt. Men det händer sällan att jag tar fram en renodlad begreppsmodell. Och det är jag inte ensam om. I praktiken gör man som informationsmodellerare sällan en särskild begreppsmodell. Orsaken är att det blir för tungrott att ha både en begreppsmodell och en informationsmodell som ska utvecklas i synk, samt att det nästan alltid är tillräckligt att analysera, definiera, dokumentera och hantera begreppen i en informationsmodell. Det är en mycket viktig uppgift som kan hanteras bra av informationsmodellen. Dock slarvas det ofta bort.

Hur kan vi låta informationsmodellen fungera som en begreppsmodell?

Först måste vi förstå att inte alla begrepp som kan finnas i en verksamhet har plats i en informationsmodell. En informationsmodell kan beskriva mycket, men det är ändå begränsat till de företeelser som verksamheten behöver hantera förekomster av, samt dessas egenskaper och relationer, inklusive förekomster i uppräknade värdemängder. Om de begrepp vi är intresserade av är de begrepp som kan finnas i den sfären, vilket torde vara nästan alla centrala begrepp i en verksamhet och ofta blir fler än tusen i en vanlig organisation, så kan vi hantera dem i en informationsmodell.

Skillnaden blir att begreppen inte bara representeras av boxar i diagrammet utan även entiteter (till exempel Kund), attribut (till exempel Kundtyp) och förekomster av uppräknade värdemängder (till exempel Kundtyp P).

För alla dessa begrepp behöver vi hantera följande:

  • namn, både normativa namn och förekommande synonymer
  • definitioner, till exempel:
    • Kund är en person eller organisation vi erbjuder våra tjänster
    • Kundtyp är en typ en kund kan vara av med avseende på…
    • Kundtyp P – Privatkund är en kund som är en privatperson.

Jag tycker att det är viktigt att som informationsmodellerare känna till och behärska begreppsanalys, begreppsmodellering och hur man kan jobba med verksamhetens begrepp och språk. Och inte minst hur man inkorporerar det i arbetet med informationsmodeller.

Det är svårt att tänka sig att man kan informationsmodellera utan att definiera begrepp. Låt oss då göra det bra! Följande artiklar fortsätter på det temat.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 12 maj. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se