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

Om begreppsanalys

Man kan inte göra en informationsmodell utan att analysera och definiera de begrepp som modellen rymmer. Som modellerare gör man egentligen alltid en begreppsanalys, medvetet eller omedvetet, genomarbetad eller slarvig, bra eller dålig. Begreppsanalys är på så sätt alltid en integrerad del av informationsmodellering. Låt oss göra det bra! Denna och följande artiklar ger den grund du behöver. 

Vad är begreppsanalys?

Begreppsanalys behöver inte alls ha något att göra med informationsmodellering. Vi kan göra det när helst vi djupare behöver förstå och definiera de begrepp som förekommer inom ett område. Vi gör det genom att reda ut hur begreppet ifråga förhåller sig till närliggande begrepp. 

Man kan som sagt tänka sig att man analyserar begrepp utan att det har något med en informationsmodell att göra. Men när vi informationsmodellerar är det omvänt, då måste vi alltid analysera och hantera begrepp. Man kan inte tänka sig informationsmodellering utan att det har en kärna av begreppsanalys i sig. Att arbeta med begrepp och språk är centralt för oss som tar fram informationsmodeller. Men det är sällan man behandlar det som ett ämne i kurser och böcker om informationsmodellering. Det är synd. Denna och följande artiklar vill fylla den luckan.

Informationsmodelleringens två perspektiv

Ett sätt att se på informationsmodellering är att vi analyserar och beskriver de företeelser som en verksamhet hanterar och vilken information som behövs för detta. För att göra det behöver vi tillämpa två olika perspektiv:

  1. Begreppsanalys: Vilka är företeelserna och vilka begrepp används för företeelserna och deras egenskaper, relationer och tillstånd? Vad betyder de ord vi använder? Behöver vi andra begrepp eller benämningar?
  2. Informationsanalys: Vilken information har vi, eller behöver vi ha, för att hantera företeelserna? Hur ska vi strukturera informationen på bästa sätt?

Ofta, i teoretiska beskrivningar av verksamhetsmodellering, försöker man hålla isär dessa två perspektiv. Man har då tänkt sig att man först gör en begreppsanalys och sedan, först då denna är klar, en informationsanalys som bygger på begreppsanalysen.

Men det är ett alltför teoretiskt synsätt för att vara gångbart i praktiken menar jag. Det handlar visserligen om olika perspektiv men i vår vardag som informationsmodellerare är dessa så ömsesidigt beroende av varandra att vi behöver jobba med båda perspektiven samtidigt. Vi behöver ständigt och sömlöst växla fram och tillbaka mellan dessa två perspektiv.

Men det hindrar inte att vi här och nu behandlar begreppsanalys som ett ämne i sin egen rätt. Detta för att vi riktigt ska förstå vad det handlar om.

Meningstriangeln

Centralt för begreppsanalys är att på djupet förstå skillnaden mellan termer och begrepp. Den bild som man då brukar visa kallas för meningstriangeln, eller ibland semiotiska triangeln.

Semiotik eller semiologi är studiet av tecken. Med tecken menar man i detta sammanhang inte bara det vi till vardags tänker på när vi säger tecken eller symboler utan också termer. Termer är de ord vi använder och är också att se som ett slags tecken eller symboler.

Tecken är allt det vi använder för att på ett eller annat sätt symbolisera, beteckna eller stå för ett begrepp.

Observera att när man inom semiotiken säger ”begrepp” menar man inte själva ordet (termen) utan det som ordet står för i vårt medvetande.

Triangeln kan också kallas Aristoteles triangel eller Ogden & Richards triangel.

Meningstriangelns tre hörn visar vad vi rör oss med när vi tänker på och benämner företeelser.

Dels har vi företeelserna i verkligheten. Det kan vara djuret katt. Sedan har jag på något sätt lärt mig att det finns något sådant och vad som utmärker det. Jag har bildat mig begreppet katt. Ett begrepp är alltså i detta sammanhang min föreställning, min idé om företeelsen i verkligheten, alldeles oavsett vad jag kallar den för.

Sedan har jag själva namnet eller termen som jag använder för att referera till företeelsen och kommunicera med (som man inom semiotiken ofta kallar tecken eller symbol):  ”katt”.

Dessa tre saker kan röra sig tämligen fritt i förhållande till varandra. Företeelsen i verkligheten finns där vare sig vi kan tänka på den eller har namn för den. Vi kan ha olika föreställningar om företeelsen. Man kan tänka sig att vi blandar ihop olika företeelser och därmed inte skiljer på dem i huvudet.

Framförallt är det viktigt att skilja på termer och begrepp. Vi kan ha olika termer för samma begrepp. Det kallar vi för synonymer. Till exempel ”katt”, ”cat”, ”kattracka”, ”kissekatt”.

Vi kan också ha olika begrepp för samma term. Det vill säga att en term har flera betydelser. Det kallar vi för homonymer. ”Katt” är enligt ordboken inte bara ett djur utan också en piska som använts som straffredskap till sjöss samt en talja varmed skeppsankare säkrades förr.

Den gemensamma förståelsen

Meningstriangeln säger dock bara vad som rör sig i mitt eget huvud, och relationen mellan min förståelse och det jag uppfattar och benämner. Vanligen är vi flera personer som behöver ha en tillräcklig gemensam förståelse (gemensamma begrepp) och ett gemensamt språk (gemensamma termer).

Men jag kan aldrig, i mitt huvud, komma åt förståelsen (begreppen) i ditt huvud, och du kan inte heller helt uppfatta förståelsen i mitt huvud. Det vi kan jobba med för att vara säkra på att vi har en tillräckligt bra gemensam förståelse är definitioner, det vill säga beskrivningar som bestämmer eller avgränsar betydelser, samt att vi hittar användbara termer som är så tydliga som möjligt för att förmedla denna gemensamma förståelse.

Skilj mellan begrepp och term!

Termer är de ord vi använder för att namnge företeelser. ”Katt” är alltså inte ett begrepp utan en term. Själva begreppet, vad en katt är kommer vi åt på ett annat sätt, genom en definition. Definitionen är kanske ”litet smygjagande rovdjur i familjen kattdjur”.

Vid modellering händer det alltid att deltagarna har olika uppfattning om termers betydelse, och vilka termer som är bäst att använda. Ett bra sätt att underlätta den dialogen är att skilja på diskussionen om begrepp och diskussionen om term, det vill säga att vi först säkerställer att vi diskuterar samma företeelse. Det gör vi enklast genom att först diskutera och komma överens om en definition. Om vi först kommer överens om att företeelsen vi diskuterar är ”person eller organisation som vi erbjuder våra tjänster”, så kan vi först därefter diskutera om den term vi ska använda är ”kund”, ”gäst”, ”besökare”, ”användare” eller ”brukare”. Det brukar bli lättare om vi gör på det sättet. Annars riskerar vi att tala förbi varandra.

Definitioner är viktiga. Det är vanligt att det med tiden visar sig att man menar olika saker med en term. Det är kanske den vanligaste orsaken till risker, fel, förseningar, skenande kostnader och strul i största allmänhet i projekt som omfattar integrationer av olika slag.

Kommande artiklar

Följande artiklar i denna serie kommer att handla om detta; Vad begreppsmodellering är, hur vi kan vårda och utveckla vår verksamhets begrepp och språk, hur vi hanterar begrepp och termer i våra informationsmodeller, samt hur vi kan skriva bra definitioner och ge bra namn på saker och ting.     

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 5 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

Informationsmodellering: Om hur vi kan representera mängder, sammansättningar och specialiseringar i ER-diagram

En företeelse kan ha ett nära beroende till en annan företeelse på ett eller annat sätt. Ofta vill vi se det som att den beroende företeelsen är underställd den andra. Det är viktigt att vi kan förmedla detta tydligt med grafiken i ett ER-diagram. Hur gör vi detta?

I ER-diagram uttrycker vi ju beroenden mellan entiteter med relationslinjer. Men vissa typer av relationer är annorlunda än andra. De innebär en tätare bindning. Jag tar upp dessa och diskuterar hur vi kan representera dem i ett ER-diagram.

Mängd (aggregation)

Det är ofta så att förekomsterna av en entitet ingår som en medlem i förekomsten av en annan entitet. Ett exempel kan vara böcker i en boksamling. En viss bok kan vara medlem i en viss boksamling.

I UMLs klassmodeller kallas det för en mängd (aggregation).
Medlemmen i en mängd har en egen oberoende existens. Det betyder att medlemmen (en bok) finns kvar då en förekomst av huvudentiteten (den boksamling den tillhör) upphör att existera. En medlem av en mängd kan också byta tillhörighet och bli medlem av en annan mängd, det vill säga lämna en boksamling för en annan.

Medlemmen (boken) kan visserligen sägas vara underställd mängden (boksamlingen) men bindningen är inte permanent. Den är inte existentiell. De vill säga att boken kan existera utan att den tillhör en boksamling, den kan byta boksamling och den kan fortsätta att finnas efter det att boksamlingen läggs ner.

Som jag tidigare har nämnt i artikeln ”Saker jag stjäl från UML” så finns det ingen mening med att se den typen av relation som någon som utskiljer den från andra typer av relationer. Martin Fowler ägnar en hel uppsats till att avfärda att ”mängd (aggregation)” skulle vara en form av relation som behöver markeras särskilt i ett klassdiagram. Självaste Jim Rumbough, en av grundarna till UML, liknade den särskilda symbol som UML använder för mängd, en ofylld romb, vid placebo. En mängd är helt enkelt inget annan än en vanlig association med en kardinalitet min 1 – max 1 , och därför är det tämligen meningslöst att ha en särskild symbol.

Men trots att bindningen inte är permanent så finns det ändå ett beroende som säger att boken är underställd boksamlingen. Jag tycker att det är viktigt att uttrycka det på något sätt och gör det genom att placera den underställda entiteten (bok) under den andra entiteten (boksamling) i ER-diagrammet.

Sammansättning (composition)

Det finns samlingar av förekomster som skiljer sig mot mängd på så sätt att en förekomst inte kan ha en egen existens. Det vill säga att medlemmen aldrig kan existera för sig själv, oberoende av den samling den tillhör, samt att den aldrig kan byta samling. Ett typiskt exempel är hur en fakturarad hänger ihop med en faktura. I UML kallas den konstruktionen sammansättning (composition) och markeras i UMLs klassdiagram med en fylld romb. (Observera att jag använder en ofylld romb, eftersom Microsoft Visio saknar fylld romb som standard för start eller slut på linje.) 

Observera att det är en helt annan typ av relation än en vanlig association, och också annorlunda än en mängd. Jag tycker att det är en så pass annorlunda relation att den behöver markeras särskilt i en informationsmodell. Jag är inte ensam om detta. De flesta notationer för ER-diagram har sina egna sätt att markera detta.
Jag kör UMLs variant med en romb, men eftersom en fylld romb inte finns med som standardalternativ i MS Visio brukar jag ta mig frihetet att använda en ofylld romb i stället.

Vanlig layout av hierarkier

Mängder och sammansättningar bildar ofta hierarkier i flera nivåer. Här är ett exempel på hur detta kan gestaltas i ett ER-diagram. Lägg märke till att skiv- och boksamlingar är mängder, det vill säga att CD-skivor och böcker existerar oberoende av om de finns med i några samlingar eller inte. De är alltså vanliga mängder och behöver därför ingen särskild symbol. Detta till skillnad mot spår på en CD-skiva eller kapitel i en bok. De försvinner då man raderar skivan eller boken. De är således sammansättningar (compositions) och relationen är därmed av en helt annan natur och förtjänar att märkas ut särskilt. Vilket jag som sagt gör med en romb.

Det är vanligt att man gestaltar hierarkier i ER-diagram som exemplet visar, i vertikala kolumner. Men jag använder ofta en annan layout, som jag presenterar i det följande.

Alternativ layout av hierarkier

Här är exakt samma hierarki som i föregående exempel men där entiteterna placerats med indrag i förhållande till de entiteter de är underordnade. Detta sätt att rita ger fördelar menar jag, speciellt i lite mer omfattande ER-diagram.

Dels kan det ofta bli en mer kompakt layout, och dels kan det ge en tydligare ordning. Speciellt då man behöver dra många relationslinjer från entiteterna i hierarkin till andra delar av ER-diagrammet. Entitetsrutorna blir då inte lika mycket i vägen för varandras relationslinjer som då de ligger ordnade i kolumner och rader. Fördelen framgår kanske inte så tydligt i detta exempel, men jag har funnit det användbart. Att kunna ha många olika alternativ till hands för hur man kan placera entiteter i förhållande till varandra ökar vilken uttryckskraft vi kan få till för att förmedla hur sake och ting hänger ihop.

Specialisering (subtypning)

De finns en helt annan typ av relation mellan entiteter. Det är när en entitet (subtyp) är en mer specialiserad variant av en annan entitet (supertyp).

Ett exempel kan vara att faktabok och skönlitterär bok (subtyper) är två specialiseringar av bok (supertyp).

I UML markeras det med en ofylld triangelformad pilspets i änden på associationslinjen i riktning mot supertypen. Jag använder den symbolen när så är lämpligt. (När jag inte använder notationen att subtypen är inskriven i supertypen.)

Specialisering kan som exemplet visar ritas med indrag på samma sätt som jag visat ovan för mängd och sammansättning.

Exempel från verkliga informationsmodeller

Här har vi två exempel på hur hierarkier med indrag kan se ut i verkliga diagram.

Hur gör du?

Det här är ju till stor del mina egna idéer om hur man i ett ER-diagram kan representera olika vanliga strukturer hos företeelser i en verksamhet. Du har säkert andra idéer. Berätta gärna!

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 28 april. 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

Historier från dataträsket del 3: Hur jag lärde mig ”Non-invasive Data Management”

När man bygger upp en förmåga i en verksamhet bör man inte forcera utan låta förmågan mogna fram.

För femton år sedan hade jag en roll som informationsarkitekt på ett finansföretag. Där fanns det mycket att hugga tag i. Företaget hade slagit ihop företag i olika länder och hade i och med det flera olika system och produktportföljer.

Problemområdet

Ett problemområde på detta företag var produktdata. Om man tog ut en lista på alla produkter de hade sålt så blev det över tusen.

Eller var dessa egentligen inte produkter? Kanske var det olika varianter av ett något mindre antal produkter. Vad var det egentligen som bestämde ifall två olika tjänster man erbjöd kunderna skulle ses som två olika produkter eller två varianter av en och samma produkt? Och kunde man samla produkter i olika produktprogram? Kunde man klassa dem som olika produkttyper enligt något kriterium?

Och vilken livscykel kunde en produkt ha? Man behövde ju kunna skilja på produkter som erbjöds och sådana som inte längre erbjöds, samt de som av någon anledning tillfälligt var ur spel. Och vilken standard skulle man ha för att ge produkter namn, både interna och externa namn?

Det fanns ingen ordning på allt detta, eller i varje fall ingen gemensam överenskommen ordning. Det var därför svårt att analysera hur produkterna presterade, och att över huvud taget överblicka och hantera produktportföljen.

En arkitekt tog fram hela listan med produkter (eller om det nu var produktvarianter?), och började sortera dessa i Excel för att försöka finna någon ordning. Han gav dock upp efter några dagar och jag fick ta över.

Min första idé: En tentativ produktkatalog

Men hur skulle jag nu få ordning på detta? Hur skulle jag gå till väga? Vem skulle kunna ge mig kriterierna för att bygga upp den produktstruktur som behövdes?

När man ska utreda något komplicerat är ett bra sätt att påstå något på prov, komma med en hypotes, som man låter sakkunniga kritisera. Det är lättare än att utifrån ett blankt papper fråga hur det ska vara. Ty sakkunniga kan ofta inte förklara hur de vill ha det, i varje fall inte så jag kan förstå. Men de kan alltid, när det jag presenterar för dem, se vad som är rätt eller fel. 

Jag skapade därför något som jag kallade för Product Catalogue vilket bara var ett Word-dokument med ett kapitel för varje produkt och med listor av varianter under dessa. Det vill säga vad jag förmodade, eller snarare killgissade, kunde ses som produkter.

Min andra idé: Produktcheferna är de viktiga intressenterna

Med denna katalog gick jag så till de jag trodde borde kunde ha intresse av detta, nämligen produktcheferna. Så här gick det:

Jag: Det borde vara viktigt för dig att förstå vad din produkt är för något.

Produktchefen: Nej, inte ett dugg.

Jag: Nu förstår jag inte alls. Varför inte?

Produktchefen: Så här går mitt jobb till. Jag ser ett behov hos kunder. Om vi inte har en produkt som möter det behovet, och finner det intressant att erbjuda någon sådan, så vi fram det som behövs. Och jag struntar fullständigt i om ni vill kalla det för en ny produkt, en variant av en befintlig produkt eller något annat.

Jag blev lite chockerad över svaret, men mest över hur fel jag tänkt. Hur skulle jag då göra? Vem var det som behöver ordning och reda i produktstrukturen, och kan hjälpa mig med hur denna ordning skulle se ut?

Min tredje idé: Affärsanalytikerna

Efter lite trevande hittade jag de som verkligen var intresserade av ordning och reda i produktstrukturen. Det var affärsanalytikerna, de som gjorde analyser och tog fram rapporter om hur olika produkter presterade. De hade idéer om vad en produkt borde vara, och allt annat runt klassificering och indelning av produkter.

Då fick jag ett spår att hålla mig till. Jag visade dem min tafatta indelning, de pekade ut vad som såg fel ut, och jag gjorde om strukturen och namngivningen. Så höll vi på ganska många vändor tills det såg riktigt bra ut. Ur detta kunde jag härleda vilka karakteristika som definierade en unik produkt, samt en massa andra regler för att styra produktstrukturen.

I katalogen tog jag även med gamla och för länge sedan utgångna och ofta exotiska produkter, och många undrade varför. Jag tyckte att det var viktigt för att förstå hur produkter kunde variera. Den struktur vi tog fram behövde vara hållbar över tiden. Den skulle ju även kunna härbärgera framtida produkter och vi måste därvid ta höjd för alla tänkbara variationer.

Vem skulle äga produktstrukturen och produktkatalogen?

Utöver affärsanalytikerna var det inte just någon som visade intresse. Arbetet flög under radarn. Det var ingen som hade beställt det. Tanken från min sida var att få någon som kunde vara ägare och förvaltare av produktstrukturen, inklusive namngivning etcetera. Det vill säga någon att gå till då man ville ha en ny produkt. Någon som kunde säga: ”Men då blir det inte en ny produkt utan en variant av den här produkten.” Och ”namnet på produkten ska följa den här regeln”, och så vidare.

Samt förstås att i längden skapa ett digitalt produktregister.

Vi fick själva agera som ägare tills vidare

Att hitta ägare till produktstrukturen och produktdata var svårt. Jag och en medarbetare bland informationsarkitekterna tog till slut själva ansvar och agerade som ägare tills vidare. Vi berättade vad vi gjorde och varför, så fick den som hade något att invända protestera. Sedan gick tiden. Affärsanalytikerna fick så småningom förtroende för allt vi gjort, inte bara med produktstrukturen utan också allt annat vi modellerat, och hur det gav ordning åt det BI-program som vi stödde. Från början hade de varit både ointresserade och skeptiska. Detta då de inte haft någon vidare bra erfarenhet av it-sidan över huvud taget. De tyckte inte att de fick tillgång till de data de ville ha. Men när de såg vad vi gjort och att det gick framåt blev de intresserade.

Produktkatalogen blev prioriterad

En händelse inträffade som gjorde produktkatalogen till något prioriterat. Företaget fick en ny produktchef. På ett möte med hela företaget sa han att han låg och studerade produktkatalogen på kvällarna, för att förstå vilka produkter vi hade. Genast fick produktkatalogen uppmärksamhet och prioritering hos både it-ledning och verksamhetsledning.       

Vi fick ägarskap

Och plötsligt en dag fick vi en ägare till produktstruktur och produktdata. Det var en av informationsarkitekterna som på ett möte med verksamheten sagt att vi behövde en ägare. Och de flesta på mötet förstod inte alls vad hon pratade om. Mötesledaren började fråga runt bordet om någon förstod det hela. Vad var det som skulle ägas, vad innebar ett ägarskap och varför var det viktigt?

Chefen för affärsanalytikerna var den som inte såg ut som en fågelholk i ansiktet och sa: Javisst, det är klart vad det är. Och det är viktigt. Raskt blev hon utsedd till ägare.

Det var precis rätt person och på rätt plats i organisationen. Och vid rätt tidpunkt. Vi hade inte forcerat fram detta utan låtit detta mogna fram. Det löste sig på så sätt naturligt då organisationen och personerna blev mogna för den rollen.

Vad jag lärde mig

Sensmoralen i denna historia är enligt mig:

  • Be inte om lov för att göra det du vet behöver göras. Gör det ändå.
    Ingen hade bett mig om att ta fram en produktkatalog. Ingen trodde att det var möjligt eller att det skulle ge någon nytta. Ingen förstod vad det var och att det var möjligt att skapa något sådant. Ändå var det precis vad de behövde och förmodligen hade det inte kunnat göras på något annat sätt. Att skapa något nytt kräver envishet och att man vågar tro på det man gör, trots motgångar.
  • Forcera inte fram ägarskapsroller och befattningsbeskrivningar. Låt det mogna fram i organisationen. Men gå före och visa vägen, på ett konkret och praktisk sätt.
    Det är inte bra att bara utnämna någon till informationsägare. Det behöver mogna fram. Bob Seiner, en auktoritet inom Data Management kallar den strategin för ”Non-invasive Data Management”. Egentligen behöver allt mogna fram när det handlar om verksamhetsutveckling. Man ska aldrig forcera fram saker. Det blir inte bra om organisation och människor inte hänger med i svängarna. Man får då en organisation på papperet men som aldrig kan fungera på riktigt. Men inget mognar fram utan att man är där och går före, sår frön, vattnar, gödslar och binder upp det som spirar.
  • Vänta tills turen dyker upp, men förbered dig så att du är beredd när den kommer.
    En ny produktchef gjorde att produktkatalogen fick prioritet. Men det hade aldrig hänt om jag inte tagit fram den innan, utan egentligt lov och utan egentligt mandat.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 21 april. 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

Historier från dataträsket del 2: Hur jag lärde mig vad som är viktigt i ett dataintensivt projekt

Vad är egentligen viktigt i ett projekt som involverar data i stor mängd?
Det här är en historia jag brukar dra ibland. Den handlar om banken som gick vilse och hittade rätt igen.

Det var 00-tal och jag hade ett uppdrag på en större bank. Jag fick då en förfrågan från en annan del av banken om jag kunde ta ett annat litet uppdrag vid sidan om.

Bakgrunden

På den tiden hade alla banker gjort vad de kunnat för att uppfylla kraven för regelverket Basel 2.
En anpassning till Basel 2 krävde omfattande analys- och rapporteringsmöjligheter och därmed en mycket genomgripande integration och analys av data från många olika källor. Att inte uppfylla de hårda kraven, att bli underkänd av Finansinspektionen, skulle bli mycket mycket dyrt för banken.

Banken hade genomfört ett mycket trassligt Basel 2-program och klarat kraven men endast nätt och jämnt, och med många anmärkningar. Finansinspektionen hade en dryg lista på åtgärder vilka man krävde att banken skulle åtgärda omedelbart, för att inte sänka bolaget.

Ledningen var nervös och hade skapat ett särskilt team, en ”special task force”, för att hantera problemen. Men tiden gick och de hade inte kommit någon vart. Teamet, som bestod av olika mellanchefer, förstod varken problemen eller vad man kunde göra. Av någon anledning vände man sig till mig, och bad mig att utreda saken. Jag tyckte inte att jag hade tid och tackade nej. Men de återkom efter några veckor och bad mig på nytt om jag i varje fall kunde göra en snabbutredning. Denna gång kunde jag inte tacka nej.

Mitt uppdrag

Det var bara att börja. Jag fick namn på några nyckelpersoner jag kunde intervjua. Både sådana som varit med om själva Basel 2-projektet och som hade tagit fram lösningen, och de som ingick i det förvaltningsteam för lösningen som jobbade med att försöka komma till rätta med bristerna.

Vad jag fick reda på om det genomförda Basel 2-projektet

På så sätt fick jag så småningom reda på hela historien, utifrån olika synvinklar. Projektet visade sig ha varit något av en mardröm. Det här var en bank med en stor och kompetent it-avdelning, väl rustat för ett sådant stort projekt. Man hade egenutvecklade system som fungerade bra, och utvecklade nya lösningar i god takt.

Men när det kom till Basel 2 hade något gått snett mellan verksamhet och it. Jag fick inte klarhet i precis vad som hade hänt. Det gick rykten och det hela var ett känsligt ämne. Kanske att it-sidan inte fick den budget de tyckte att de behövde för att genomföra den stora förflyttningen. Kanske att it-folket då upplevdes som krångliga att jobba med. Verksamhetsledningen vände sig i stället till en it-leverantör som sade sig ha ett standardsystem som hade en färdig lösning för Basel 2. Leverantörens säljare påståstod att de skulle genomföra projektet på tre veckor. En vecka för dataanalys, en vecka för att konfigurera systemet och en vecka för att ta fram de rapporter som krävdes. Jag tror att det kan ha varit detta som fick it-avdelningen att helt och hållet ta sin hand från allt som hade med Basel 2 att göra.

Det tog såklart lite längre tid än tre veckor. Leverantörens folk hade mycket dålig kunskap om hur man genomför ett sådant stort projekt. Och de fick nog inte mycket hjälp från it-sidan, skulle jag tro. Ryktet sa till exempel att leverantörens folk först ett år in i projektet förstod att bolaget hade verksamhet i fler länder än Sverige.

Men efter två års arbete fanns det inte mycket att göra, alla tidsfrister hade gått ut och man fick med knapp nöd godkänt av Finansinspektionen, fast med en lång restlista.

Vad jag fick reda på om Basel 2-lösningens ursprungliga förvaltningsteam

Efter driftsättningen hade man skapat ett särskilt förvaltningsteam som skulle beta av problemen. Det verkade som om it-avdelningen fortfarande inte ville ta ansvar på riktigt utan bemannade med folk från lite olika håll, bland annat från ett uppköpt bolag. När jag kom in i bilden hade detta pågått till ganska nyligen och upplevelsen var att de inte kom framåt, trots en stor bemanning. Och Finansinspektionen låg återigen på och hotade med stränga åtgärder.

Jag intervjuade några som varit inblandade. De vittnade om att arbetsprocessen för förvaltningen hade varit mycket byråkratisk. Den leddes av personer som inte hade det pragmatiska sättet att samarbeta som de var vana vid. Verksamheten, som till största delen var bankens riskanalytiker, var frustrerade. De var tvungna att komma in med en skriftlig begäran om vad man ville ha gjort innan teamledaren initierade åtgärd. Riskanalytikerna visste sällan själva vad som var felet och hade därför svårigheter att ens specificera vad de ville ha gjort. Och att föra en dialog med förvaltningsteamet var tydligen helt uteslutet. Förvaltningsledaren ville ha en tydlig och kontrollerad inkanal och en process som förhindrade vad han upplevde som smitvägar.

Den överraskande vändningen

Så här hade det varit fram tills ett par månader innan jag blev inkopplad. Bolagsledningen och den särskilda utredningsgruppen var vid det läget stressade. Kraven från Finansinspektionen tycktes vara omöjliga att uppfylla av förvaltningsteamet, trots en stor bemanning och skenande förvaltningskostnad.

Men det hade just då hänt något som ännu inte nått deras öron. Något som i ett slag förändrade bilden. Jag fick reda på det hela från riskanalytikerna.

Teamledaren från förvaltningsteamet hade gått hem på föräldraledighet. It-ledningen hade då passat på att ändra bemanningen. Man hade tillsatt en förvaltningsledare som var mycket mera smidig, samt skickat in två erfarna män i teamet för att leda arbetet rent praktiskt. Då förändrades allt i ett slag.

Det intressanta var vad de två garvade männen kunde och vad de gjorde. Och än mera intressant vad de inte kunde. De hade inte alls den kunskap man kanske skulle kunnat förvänta sig ge resultat. De hade inte kunskap om vare sig Basel 2-regelverket, Basel 2-lösningen eller Business Intelligence, som det ju i mångt och mycket handlade om.

Men i stället kunde de något annat, vilket visade sig vara det viktiga. De hade god kunskap om bolagets alla operativa system, och de källdata som fanns där och som födde Basel 2-lösningen. Och de visste vem de skulle ta en snabbfika med för att reda ut det de inte visste. Och framför allt, de hade ett helt annat arbetssätt än förvaltningsteamet hade haft fram till dess. I stället för att vänta på en beställning på exakt vad verksamheten ville ha gjort, förde de en dialog med de viktiga verksamhetsanvändarna, det vill säga riskanalytikerna. De ställde sig framför en whiteboard tillsammans med verksamhetsanalytikerna och diskuterade problem och lösningar. Riskanalytikerna jublade över skillnaden. Att det inte längre handlade om en envägskommunikation där en part ställde krav och den andra parten levererade lösning. Utan att man tillsammans diskuterade problem och möjliga lösningar och prövade dessa i små steg.

Dessa två medelålders män hade inte gått någon Agile-kurs. Jag är osäker på om de ens hade hört talas om moderna agila arbetssätt. Men de visste av erfarenhet att ett tätt och kontinuerligt tvär-funktionellt samarbete var det som krävdes.  

Så allt gick helt plötsligt åt rätt håll nu. Det fanns mycket att göra, men man betade av saker och ting i en stadig takt.

Min rekommendation till ledningen

För mig var det bara att avsluta utredningen och skriva rapport. Jag föredrog för utredningsteamet och it-ledningen vad jag kommit fram till. Det är nog det trevligaste jag någonsin rapporterat. För jag rekommenderade att man bara hade att fortsätta på samma sätt. Det fanns mycket att göra framöver, men det hände saker, och allt var på väg åt rätt håll. Fast mitt budskap att man inte fick skära ner budgeten förrän man kommit längre i att beta av problemen fick några pannor i församlingen att rynkas.

Vad jag lärde mig

Sensmoralen tycker jag är följande: Kunskap om data är avgörande, viktigare än annat, i alla satsningar som är dataintensiva. Och kanske ännu viktigare är ett nära och informellt och interaktivt arbetssätt.

Allt annat väger ganska lätt. Samt: Lita inte på standardsystem-säljare. De vet sällan vad de talar om.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 14 april. 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

Historier från dataträsket del 1: Hur jag lärde mig att verksamhetsexperter inte kan allt

Jag tänker att jag i några artiklar ska berätta några historier som jag varit med om, och som man kan reflektera över. Först ut är historien om hur jag på ett ganska brutalt sätt lärde mig grunden i vad det innebär att modellera en verksamhet. Eller snarare vad det inte innebär. Hur man absolut inte ska göra.

Låt mig berätta en historia jag tänker på ibland. Det var en gråkall vårvinter i Stockholm i början av 90-talet. Jag var färsk från universitetets datalinje och hade fått mitt första jobb som systemutvecklare. Ett försäkringsföretag behövde ett administrativt system som skulle fungera som en central punkt i verksamheten. Det fanns redan färdiga informations- och processmodeller som skulle fungera som specifikation. De hade tagits fram i en serie workshops ledda av ett konsultbolag. Så nu var det bara att bygga efter ritning. Det vill säga att de var så det sades.

Men alla som varit med i branschen vet ju att sådana i förväg framtagna specifikationer är tämligen intetsägande. Vanligen är de på samma gång dels alldeles för grova och dels alldeles för detaljerade. Där de går ner lite mer i detaljer blir det nästan utan undantag fel. Orsaken är nog självklar för de flesta idag. Det går inte att i förväg specificera vad som verkligen behövs. Utveckling måste alltid vara iterativ, man måste experimentera sig fram, ställa upp hypoteser, prova vad som fungerar och modifiera alltefter man lär sig.

Men på den tiden, och även långt senare, fanns det en naiv tro på att man kunde specificera saker i förväg. Det var en hel industri, konsultbolag som tog fram hela pärmar av modeller och specifikationer. Det finns det nog fortfarande de som gör, men det är ovanligt.

Det var uppenbart för mig redan efter första dagarna att jag måste ta fram allt från grunden, inte minst en datamodell att basera databasen på. Pärmen jag hade fått i handen var inte till mycket hjälp, annat än att den i varje fall ringade in vilka områden man hade tänkt sig att man behövde it-stöd för.

Nåväl, jag satte igång med ungdomlig energi. Mest handlade det om att se vilka data som hanterades idag och vad man tyckte sig ha behov för framöver. Det gick ganska lätt. Men några begrepp hade jag svårt för. Ett av dessa var det mest centrala begreppet ”Försäkring”. Som alla vet som har sitt boende eller bil försäkrad så får man ju en ny version av försäkringen varje år. Är det då en ny försäkring eller är det samma?

Mitt första möte med en verksamhetsexpert  

När jag besvärade kontorsfolket med denna och andra frågor blev jag hänvisad till Arne, bolagets mest seniora expert. ”Arne kan allt. Han är en legendar i branschen”. Vad bra tänkte jag, nu kan jag få riktigt bra svar på mina frågor. Så här gick min intervju:

Jag: Det som löper över flera år, är det en försäkring?

Arne: Ja.

Jag: Det som jag får nytt varje år, vad är det?

Arne: En försäkring.

Jag: Men du sa ju att det som löper över flera år är det som är en försäkring?

Arne: Jo.

Jag: Men det är ju olika saker?

Arne (nu lite irriterad): Ja, men det är en försäkring.

Och så vidare. Så höll vi på ett tag. Och Arne började nu bli röd i ansiktet.

Då fick jag infallet att passa på att reda ut något annat. Nämligen vad den korrekta termen är för själva det papper man får hem som det står ”Försäkring” på. Det var ingen bra idé. Arne kallade också detta för ”försäkring”.

Nu var jag förvirrad och mina upprepande frågor och påpekanden att vi behövde skilja på de olika men närliggande företeelserna. Det fick till resultat att Arne stod och dunkade försäkringsbrev i skrivbordet, så att askkoppar och aska flög. (Jo, man rökte på kontor på början av 90-talet. Svårt att tro idag.) och upprepande högljutt: ”Det här är en försäkring. Och det här. Och det här.”

Jag lämnade Arnes flotta hörnrum med tanken att det blir nog inte så lätt i den här branschen. När inte verksamhetsexperter kan svara på de mest enkla frågor.

Varför berättar jag denna historia? Jo, jag tycker att i den finns en sensmoral. Men först måste jag bara säga vad jag så småningom lärt mig i själva sakfrågan, vad de korrekta termerna är för de företeelser som jag undrade över. För det första: Inget av det jag nämnde heter formellt sett ”försäkring” även om det används som en vardaglig term. Det man tecknar med ett försäkringsbolag är ett avtal om försäkring, ett ”försäkringsavtal”, även om ingen använder det ordet till vardags. När avtalet förnyas årligen blir det rent juridiskt sett ett nytt avtal. Men i praktiken, ur alla vanliga aspekter, ser man det som en ny version av samma avtal. Man kallar då varje version för ”försäkringsavtalsversion”, om man ska vara korrekt, men oftast bara ”försäkringsversion”. Det dokument som manifesterar avtalet kallas, som alla nog vet, ”försäkringsbrev”.

Vad jag lärde mig

Men hur var det med sensmoralen i historien? Jo, jag tänker att det jag lärde mig den hårda vägen var att när man vill analysera, förstå och beskriva en verksamhet räcker det inte med att fråga verksamhetsexperter. Man kan inte förvänta sig att experter så där enkelt och rakt ska berätta för en hur deras verksamhet fungerar. Att vara bra på en verksamhet betyder inte att man nödvändigtvis kan beskriva den på ett tydligt sätt. Jag har absolut inga tvivel på att Arne var bland de bästa på området och klart och tydligt kunde skilja på de företeelser jag frågade honom om. Men det betyder inte att han därmed kunde benämna och definiera dessa saker på ett sätt som var användbart för mitt syfte.

Det är mitt jobb, som informationsarkitekt att analysera, beskriva och benämna de begrepp som verksamheten behöver. Inte någon verksamhetsexperts. Jag måste förstås fråga och föra en dialog med olika verksamhetsexperter. Men inte bara det, jag måste forska och tänka själv också. Jag kan aldrig förvänta mig att verksamhetsexperter ska vara bra på att analysera och beskriva de begrepp de använder.

Mitt andra möte med verksamhetexperter

En tid senare, när jag tyckte att jag fått ihop en någorlunda klar databasdesign, så var det en sak som återstod innan jag kunde påbörja konstruktionen. Vi behövde bestämma detaljer som fältlängder, värdeförråd, vad som skulle vara obligatoriska termer etcetera. Jag och datachefen fick då den strålande idén att göra detta i ett stormöte. Det vill säga, vi själva var väldigt nöjda med idén. Representanter från verksamhetens alla hörn skulle få vara med och bidra med sin kunskap. Intresset visade sig emellertid vara lågt, det grymtades att man minsann hade viktigare saker att göra, viktiga kundmöten och nya avtal som man behövde få fram. Men vi trumfade igenom ett stormöte till slut, med många deltagare, allt från chefer och stjärnsäljare till sekreterare och assistenter. Vi började ställa våra frågor. Hur långt kan ett kundnamn vara? Hur stort belopp kan en försäkringspremie vara på? Måste en försäkring alltid ha provisionsprocenten angiven?

Irritationen växte i salen. Varför ska jag var med här tyckte vissa, det här är inte mitt område? Andra: ”Det här är en teknisk fråga, jag har bättre saker att göra”. Varje fråga möttes av vilda gissningar, ointresse, och ifrågasättande av om detta var deras sak. Folk började droppa av. Det gick så långt att vi fick avbryta.

Vad jag lärde mig denna gång

Vad var sensmoralen denna gång? Jo, densamma. Verksamhetsfolk kan inte allt, kan inte i detalj veta vad de behöver, har inte alltid rätt. Och bryr sig ofta inte ens. Verksamhetsexperter är inte kunniga på alla aspekter på sin verksamhet. Det är jag som verksamhetanalytiker som måste använda olika metoder och källor och rätt avväga och räkna ut hur saker hänger ihop.

Då det gäller så enkla saker som, fältlängder och existensregler för olika fält är det enklast att tröska igenom befintligt data efter extremvärden.

Jag tänker ibland på dessa händelser. Jag var oerfaren och naiv. Fast hur skull jag kunna veta att experter inte kan ge vettiga svar på frågor inom sitt område? Just dessa aspekter var ju inte deras område förstås. Borde jag ha förstått det i förväg? Kanske inte, men jag borde i varje fall ha varit mer uppmärksam när jag fick tecken på att så inte var fallet. Inte vara lika envis och mer eller mindre kräva att de skulle kunna svara. Idag hoppas jag att jag är mer ödmjuk när det gäller förväntningar på vad andra ska kunna, även sådana som är experter. Det hela kokar ner till att verksamheter är komplicerade ekosystem och ingen kan vara expert på alla aspekter av något så mångfacetterat.

Jag tycker att det illustrerar något grundläggande om kunskap och hur vi finner den. Vi ska fråga, fast inte förvänta oss att alltid få de svar vi behöver ha. Kanske du tycker att denna historia visade något du redan vet. Och det hoppas jag. Men i så fall kan den kanske tjäna som en påminnelse om vilken naiv bild andra kan ha av vad vi gör, vi som jobbar med modellering, att vi bara frågar och tecknar ner vad experter säger.  

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 7 april. 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

Informationsmodellering: Hur vi kan namnge relationer

Jag vill ge ett alternativ till den vanliga principen för att namnge relationer mellan entiteter i informationsmodeller. Syftet är att namnen ska överensstämma med namnen för de verksamhetsbegrepp som relationerna representerar. Vi får därmed en spårbarhet från relationerna i våra informationsmodeller till termer i verksamheten och i informationssystemen.

Den vanliga principen för namngivning

Det vanliga är att namnge relationer så att relationsnamnet tillsammans med entitetsnamnen blir mer eller mindre en verbal mening som går att uttala.
I exemplet till höger blir det ”Beställning läggs av Kund”. Det är tänkt att hela ER-diagrammet då blir läsbart som ett antal verbala uttryck. Det är en fördel, speciellt då det gäller ovana läsare av ER-diagram, och i varje fall då det gäller enklare diagram, det vill säga där man bara har ett antal entiteter och relationer och inga attribut.

Men jag menar att den principen för namngivning också har ett antal nackdelar, och att dessa tillsammans vida överskuggar fördelen. Jag beskriver problemen i det följande.

Problem 1: Namnen blir ofta intetsägande verb

Det blir ofta nästan omöjligt att undvika att relationsnamnen blir intetsägande verb som ”har”, ”tillhör”, ”är”. När vi talar så har dessa allmänna verb en funktion, men de kan aldrig fungera som verksamhetbegrepp. De beskriver inte vad relationen står för, i detta exempel vilken roll en kund har i en beställning. En relation har alltid en mening. De namn vi ger saker och ting bör uttrycka den meningen så klart och tydligt som möjligt.

Problem 2: Namnen uttrycker ofta handling

Om man vill undvika de mest allmänna verben, se ovan, så blir relationsnamnen ofta i stället verbsatser som uttrycker någon form av handling i tiden, som ”läggs av” i exemplet ovan. Problemet med sådana namn är just det att de uttrycker handling, det vill säga en process. Det fungerar inte så bra i en informationsmodell, som ju ska vara processneutral. Modellen ska bara uttrycka vilken information som kan finnas, inte hur den skapas.

Alla beställningar har en beställare, men så snart beställningarna finns så är beställningarna redan lagda. ”Läggs av” är historia, det var något som skedde någon gång, i det ögonblick beställningen gjordes. Det gör att informationsmodellen får drag av process, vilket är falskt. ”Lagd av” vore mer korrekt i så fall, men är ändå inte bra, eftersom det mer talar om hur relationen skapades än vad den innebär.

Problem 3: Namnen blir inte verksamhetstermer som kan användas i andra sammanhang.

Den kund som lagt en beställning är ”Beställare” på beställningen. Det är en egenskap hos en beställning. En relation är således alltid en egenskap hos en entitet samt också ett verksamhetsbegrepp som bör definieras, beskrivas och normeras. Det är det vi har informationsmodellens textdel till. Och där kan egenskapen inte heta ”Läggs av” eller ”Har”. Knappast heller ”Kund” eftersom det namnet bara uttrycker vilken klass av objekt som utgör värdeförråd för egenskapen, och inte vad relationen har för mening.

Sedan ska relationen realiseras i olika sammanhang. Den kanske blir en; databaskolumn, variabel i programkod, fält i en fildeklaration, ruta i användargränssnitt eller term i en rapport? Då, om inte tidigare, behöver vi ett tydligt namngivet, definierat och normerat verksamhetsbegrepp. Detta är enligt min mening informationsmodellens jobb. Precis som vi gör med entiteter och attribut. Då fungerar termen ”beställare”, men knappast de intetsägande namnen man ofta ser i informationsmodeller.

Vad vi vill med namngivning

Vi kan tänka efter vad vi egentligen vill med namnen, vad som är ett bra namn. Ett namn ska förstås vara så korrekt och tydligt som möjligt men också så användbart som möjligt. Det innebär att det ska fungera i så många olika sammanhang som möjligt, det vill säga alla de sammanhang som informationsmodellen kan komma att användas i. Man brukar ibland uttrycka det som att informationsmodellen ska vara process-agnostisk, det vill säga inte ha något spår av hur företeelserna kommer till eller hanteras, bara att de finns och vad de har för mening.

Jag tycker att det är viktigt att våra modeller, blir användbara som underlag för implementationer av informationssystem av olika slag. Det kan vara databaser, programkod, filer, meddelandescheman, användargränssnitt, api:er, rapporter med mera. Vi normerar ett språk för allt det som hanteras och presenteras. Då gäller det att de namn vi väljer blir så användbara som möjligt. Men då måste vi ha en namngivning som är så pass användbar att den verkligen fungerar i skilda sammanhang.

Men jag vet att det finns en mer traditionell uppfattning som säger att det inte är något värde att försöka tillämpa samma namngivning i informationsmodeller som i fysiska sammanhang. Man ser det som olika världar som ska hållas isär. Vi gör konceptuella modeller och bryr oss inte alls om det ”tekniska”, säger man. Man är alltså inte bekymrad för om informationsmodellen säger något om den fysiska verkligheten, eller ens om den är användbar i praktiska sammanhang.

Jag är av motsatt åsikt. Jag menar att vi så lång det går bör jobba ihop, tvärs över alla roller i organisationen och så långt det går ha gemensamma modeller. Det är ju det modeller är till för, att ge oss en gemensam bild, en gemensam förståelse att jobba med och att utveckla tillsammans.

Nyckeln är ”så långt det går”. Det kommer alltid att finnas skillnader mellan modeller och det modellerna används till, men låt oss sträva efter att hålla dessa så små som möjligt. Detta är en princip som kommer från den filosofi som heter ”domändriven design”, och som jag tycker är helt avgörande för vilken nytta våra modeller ska kunna ge. Jag har skrivit om detta synsätt i många tidigare artiklar.

Mitt förslag till namngivningsprincip

Mitt förslag är en namngivning som jag tillämpat i ett par decennier och som jag tycker fungerar bra.

En relation är egentligen inget annat än en egenskap hos en entitet. Närmare bestämt en egenskap som innebär att entiteten har en relation till en annan entitet. Man kan också uttrycka det som att egenskapen har ett värdeförråd (en värdedomän) som definieras av den andra entiteten, det vill säga den klass av företeelser som den andra entiteten representerar. I exemplet, som är genomgående i denna artikel, är det Beställning som har egenskapen ”Beställare”, som enligt ER-diagrammet är en obligatorisk egenskap och som har ett värdeförråd (möjliga värden) som är mängden av alla kunder.

Allt det vi behöver definiera och beskriva för övriga attribut behöver vi också beskriva för de attribut som manifesterar relationer, såsom namn, synonymer, beskrivningar, värdeförråd, format och regler. Varför ska vi då behandla relationer på andra sätt än andra attribut?

Låt oss se hur det blir när vi beskriver detta med hjälp av attribut.
Namnet på attributet skulle jag skriva ”Beställare – Kundnummer”. Ofta blir namnet lite mer specifikt än vad relationen heter. Vi vill ju kunna säga att i detta fall är det beställarens kundnummer som är egenskapen.
En del kanske tycker att man kan utelämna suffixet ”Kundnummer”. En främmande nyckel ska ju ändå alltid peka på primärnyckeln i den entitet den pekar på. Men jag föredrar att ha med det ändå. Man kan inte vara nog tydlig. Det kan ju också finnas till exempel ”Beställare – Namn”.

Nu har vi fått en tydlig spårbarhet mellan diagram och de attribut man beskriver i textdelen av modellen.

Det finns de som reagerar på det osköna i redundansen i detta sätt att göra, det vill säga att samma sak beskrivs två gånger, en gång som relation och en gång som attribut. Att en beställning har en kund som beställare beskrivs både med relationslinjen och med attributet. Man kan då undra om det är samma sak eller inte. Jag förstår invändningen, men menar att den väger lätt. Jag tycker att det är ett pris värt att betala, bara man är tydlig med namngivning och beskrivning.

Namngivning enligt databasstandard

Det finns en annan princip för namngivning av attribut som manifesterar relationer som man ofta stöter på och därför är värd att nämna. Det är det namnskicket som är vanligt i databassammanhang. I en traditionell databas är ju en relation manifesterad som en databaskolumn, vilken är en främmande nyckel, det vill säga den innehåller värden som återfinns som primärnyckel i en annan tabell. Då brukar man ge den kolumnen samma namn som den tabell och kolumn den pekar på. I exemplet ovan skulle då attributet heta Kund.Kundnummer. Fördelen för databasdesigners är att detta namnskick underlättar så att man automatiskt kan hantera relationer. Fast jag tycker att det namnskicket inte passar för en bredare användning. Man säger visserligen att kolumnen innehåller ett kundnummer men det viktigaste tycker jag ändå är att uttrycka relationens mening.

Relationers riktning

Inom traditionell data- och informationsmodellering har relationer inte någon riktning. Det beror på att informationsmodellering har ett ursprung i relationsdatabasdesign. I en relationsdatabas kan en relation traverseras i vilken riktning som helst, till exempel med frågespråket SQL. Däremot så har relationsnamnet alltid en viss läsriktning, det vill säga namnet är tänkt att läsas från en bestämd entitet till den andra. Man kan dock lika gärna behöva sätta ett namn med motsatt läsriktning. Eller ha två namn, ett åt vartdera hållet. Det finns de som förespråkar det.

Men så fungerar inte alla modelleringsspråk. I klassmodeller i UML är det annorlunda, därför att UML ursprungligen är framtaget för att strukturera objektorienterad programkod. Där har relationer alltid en bestämd riktning. Om man i programkod vill kunna traversera i båda riktningarna behöver vi skapa två relationer, en för vardera riktningen.

I programkod, liksom i olika språk för datascheman, är det dessutom vanligt att relationer går åt hållet från en till många. I programkod skulle förmodligen en kund ha en kollektion av pekare till de beställningar kunden är beställare på.

Allt detta gör att det är viktigt att vi pekar ut riktningen för våra relationer, vare sig det rör sig om att relationen verkligen har en bestämd riktning eller det handlar om läsriktning för det namn vi väljer att ge den. Jag gör det med en liten fylld pilspets som i exemplet.

En annan fördel med en sådan pilspets vid relationsnamnet ges exempel på här till höger. Ibland har man många relationslinjer som går ut vertikalt från en entitet. Då kan en sådan pilspets tydligt markera vilket namn som hör till viken relationslinje. Se de relationer som går vertikalt uppåt från entiteten ”Card Activity”.

Låt oss diskutera och utveckla vårt område!

Allt detta är förstås bara mina egna erfarenheter och åsikter, inte en slutgiltig ”sanning”. Men det är något vi borde diskutera och utveckla. Jag har saknat en sådan dialog. Det är därför jag skriver dessa artiklar.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 31 mars. 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