Taggarkiv: Informationsmodell

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

Vi kan göra bättre modeller – om gestaltning med grafik och text

Jag påstår att vi arkitekter kan bli bättre på hur vi utformar våra modeller. Mycket bättre! Detta är introduktionen till en serie artiklar där jag kommer att ge mina råd om hur vi med hjälp av bättre grafik och strukturerad text kan få våra modeller att bära mer kunskap och bli mer effektiva tanke- och kommunikationsverktyg.

Modeller är våra viktigaste verktyg

Modeller är arkitektens viktigaste verktyg. Vi arkitekter – vare sig vi är informations-, verksamhets- eller it-arkitekter – är i grunden modellerare. En nestor i branschen sa en gång: ”Jag modellerar vad som helst, var som helst, i vilket sammanhang som helst”. Jag brukar tänka på det.

Modeller är på samma gång ett tanke-, analys och kommunikationsverktyg. De blir mycket kraftfulla verktyg om vi förstår att utforma och använda dem rätt. En modell kan, rätt utformad, bli till en samarbetsplattform för lärandet i en organisation. 

Modellering är ett hantverk

Det är ett hantverk att göra bra modeller. Det kräver kunskap, vana och handlag. Och för en hantverkare är verktygen allt, de är som en förlängning av kroppen, sinnena och hjärnan. En hantverkare behöver därmed hålla sina verktyg i gott skick, så att de är skarpa och precisa.

Låt oss göra det.

Gestaltning är viktigt

En modell står och faller med hur den är utformad, i grafik och text. Om den tydligt förmedlar det som modelleraren vill förmedla, om den är krispigt klar, då gör den sitt jobb. Oavsett om den är en sann och användbar representation av det som modelleras, egentligen. Ty om modellen är tydlig går innehållet alltid att kritisera och förbättra. Den är lika mycket en fråga som ett påstående: ”Kan vi se det så här?”. Och frågor är minst lika viktiga som påståenden.

Om modellen inte är tydlig går idéinnehållet egentligen inte ens att kritisera. Ty det som man inte kan förstå kan man inte heller kritisera. Därför är det oerhört viktigt hur vi ritar våra modeller. Hela vårt yrke och yrkesområde, både som individer och som yrkesgrupp, står och faller med detta. Fast inte bara hur vi ritar. Modeller bör ha text också, och vi bör integrera grafik och text så att det bildar en helhet. Därför vill jag hellre säga gestalta och inte rita trots att grafiken har en framträdande roll.  

Hur står det egentligen till där ute?

Om man googlar på ”informationsmodell”, ”datamodell” eller liknande får man upp många olika exempel på diagram. Bilden som inleder denna artikel visar några slumpvisa träffar. Jag har inte valt ut vare sig bra eller dåliga exempel, utan bara det jag tycker kan vara representativt för hur det ser ut i våra verksamheter.

Jag tycker inte att man i något av dessa exempel, eller andra man kan hitta när man letar, har lyckats få modellerna att kommunicera på ett effektivt sätt. Vi kan göra mycket bättre, och det med enkla medel.

Hur ska man då göra?

Det finns inte mycket skrivet om hur man gestaltar modeller, och det lilla som är skrivet brukar vara upp åt väggarna enligt mig. Det är en stark åsikt och jag kommer att motivera den. Och inte bara motivera utan även visa på bättre sätt i de artiklar jag planerar att skriva framöver.

Det gäller inte bara informationsmodeller utan även andra modeller inom it- och verksamhetsarkitektur, så som förmågekartor, systemkartor, processmodeller med flera.

Låt oss bli bättre – tillsammans! 

Jag har i ett par decennier arbetat med att försöka utveckla hur man kan rita och skriva, för att göra bättre modeller. Jag har varit nyfiken på hur man gör inom andra yrkesområden där man gör modeller, ritningar, kartor och grafik i största allmänhet. Det jag lärt mig har jag sedan prövat att tillämpa på vårt område, i första hand informationsmodeller samt förmåge- och systemkartor. Och jag vill påstå att jag funnit sätt att rita och skriva, samt kombinera grafik och text, som jag menar har potential att lyfta hela vårt område. För om vi kan göra tydligare, skarpare och mer informativa modeller så kan vi bli mycket mer relevanta för våra organisationer.

Det betyder inte att jag vet och kan allt. Du kanske också har något att bidra med. Du har kanske andra insikter. Det är värdefullt om du då delar med dig. Så att vi tillsammans kan utveckla hela vårt område.

Exempel från ett helt annat område

Som en liten inledning vill jag visa ett mycket enkelt och vardagligt exempel från en helt annan bransch. Det är det elektriska kopplingsschemat till elsystemet på en bil, en Nash Ambassador från 1957. Det kanske inte är något märkvärdigt, det är så kopplingsscheman brukar ritas. Men ändå. Jag tycker att det finns så mycket klokskap och skicklighet i den grafiska gestaltningen som man kan begrunda och bara måste beundra. 

Lägg till exempel märke till följande:

  • Begränsningar: Tänk först på de begränsningar man hade: inget färgtryck samt begränsat utrymme.
  • Geografin i schemat: Titta sedan på hur man ordnat geografin i schemat. Längst upp har vi framlyktorna, sedan motorutrymmet med tändspole, fördelardosa och batteri. instrumentpanelen hittar vi långt ner på ritningen med alla strömbrytare och instrument. Baklyktorna ser vi längst ner. Hela ritningen är alltså utlagd schematiskt efter var i bilen respektive komponent sitter. Komponenterna är ordnade i grupper som är tydligt avgränsade från varandra. Man kan naturligt och utan ansträngning orientera sig i ritningen i förhållande till bilen i verkligheten.
  • Symboler: De olika komponenterna har symboler som är lätta att känna igen eftersom de avbildar komponenten ifråga symboliskt. Så länge man vet något om bil-el kan man mer eller mindre automatiskt känna igen komponenterna och behöver ingen symbolförklaring. Eller i varje fall, när man har stött på dem en gång är det lätt att erinra sig vad de står för nästa gång.
  • Linjer: Alla ledningar ritas som linjer, men de som går mellan batteri, laddningsrelä och generator är kraftigare. De representerar kraftigare kabel som ska klara starkare ström. Kabeln till startmotorn är på liknande sätt lite mittemellan i grovlek. Grovleken på linjen symboliserar hur grov kabeln är.  Linjerna är dragna med räta vinklar och ”hopp” där de korsar varandra. Linjer som ska till samma ställen är dragna tillsammans som grupp.
  • Ordning: Symboler, linjer och texter är placerade med raka marginaler. Hela diagrammet bildar en rektangel med raka marginaler.

Jag har försökt tänka hur man ska kunna förbättra kopplingsschemat ovan, men har inte hittat något sätt. Det är helt enkelt perfekt. Idag har vi förstås färgtryck, vilket skulle vara en fördel. Men i övrigt?

När jag ser vad man gjort inom detta och andra områden med grafik och gestaltning blir jag lycksalig, imponerad och ödmjuk. Det finns så mycket kunskap om hur man gestaltar ritningar och modeller inom olika yrkesområden. Det finns så mycket att lära sig av.

Varför har vi inte lärt oss?

Men varför är det så bristfälligt inom vårt område? Det vill säga allt som har med it- och verksamhet att göra. Varför har vi inte lärt oss?
Du som läser detta, tror du inte att vi inom vårt område skulle kunna bli lika bra på att gestalta med grafik och text som i andra branscher? Eller är det så att just vårt område är så omöjligt, att vi har en omöjlig uppgift? Vi kan i varje fall inte skylla på att vi är i en ung bransch. Verksamhets- och it-arkitekter har funnits i någon form i minst ett halvsekel. För mig är det en gåta. Hur har vi kunnat undgå att inte lära oss med tiden? Vad har hållit oss tillbaka? Jag vet inte, men jag tycker att vi nu har ett ansvar att bli bättre.

Hur blir vi bättre?

Vad kan vi då göra för att bli bättre? Jag vill i varje fall dra mitt strå till stacken. Jag kommer i en rad av artiklar framöver stegvis gå igenom det jag kommit fram till, med exempel och motiveringar. Några saker är kanske självklara för läsaren, några är kanske nya. Några är kanske kontroversiella i det att de motsäger sådant som annars brukar läras ut. Men jag tror verkligen att du, om du läser, begrundar och provar det som sägs kommer att utvecklas som modellerare och arkitekt.

Du behöver inte ens hålla med om allt, och det är ok. Men du kommer att bli tvungen att reflektera över hur du gör och varför.

Jag hoppas också att du vågar och vill kritisera mina råd. Det kan ju inte vara så att det bara är jag som har kunskap inom området. Eller att det jag säger är den slutgiltiga visdomen inom området. Min önskan är att fler vill bidra.

Det mesta jag kommer att skriva om framöver är mer eller mindre tillämpligt på alla slags modeller, och ibland till och med på alla slags grafiska representationer. Men en del konkreta råd gäller specifikt för informationsmodeller.

Mitt hopp är att det finns läsare som blir nyfikna på att utvecklas, som blir inspirerade till att experimentera och förbättra sina modeller i detta avseende. Det är det jag vill, så ett frö till en renässans inom området.

Vad jag kommer att beröra

Följande är en preliminär och grov plan över vilka ämnen jag kommer att ta upp i artikelserien.

  • Disposition:
    Hur vi placerar elementen i förhållande till varandra på diagrammet så att vi förmedlar vilken relation företeelserna har till varandra.
  • Struktur:
    Hur vi ger diagramytan en struktur som förmedlar hur vi ser på relationen mellan företeelserna.
  • Övergripande struktur:
    Hur vi kan ge hela modellen en meningsfull övergripande struktur.
  • Fokus:
    Hur vi lyfter fram centrala element.
  • Linjer:
    Hur vi drar relationslinjer så de blir tydliga och inte stör.
  • Namn:
    Hur vi benämner företeelserna och placerar namn.
  • Definitioner:
    Hur vi skriver definitioner och använder definitioner i diagrammet.
  • Verksamhetsregler:
    Hur verksamhetsregler har sin naturliga plats i informationsmodellen.
  • Färg:
    Hur vi använder färg.
  • Gråskalor:
    Hur vi använder gråskalor.
  • Samverkan tex och grafik:
    Hur vi får grafik och text att samverka.
  • Informationstäthet:
    Hur vi får våra modeller att förmedla allt vi behöver förmedla.
  • Diagramtyper:
    Hur vi kan utöka vår verktygslåda med fler diagramtyper.
  • Rika informationsmodeller:
    Hur vi kan få informationsmodeller att bära mycket mer kunskap och spela en mer central roll i en verksamhet.

Nästa artikel blir en rivstart.
Hoppas du vill hänga med! Om du har tankar kring detta – mejla mig: peter.tallungs@irm.se

/Peter Tallungs, IRM

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

Strategimönster för informationsarkitekter – del 3: Modellens avgränsade kontext

Vilka informationsmodeller ska vi ha för ett visst område? Skall det vara en enda mycket bred modell eller flera som var och en är mer avgränsade? Hur långt ska en viss modell sträcka sig? Var ska vi låta gränsen till omvärlden gå? Låt oss se hur man kan resonera. Denna artikel handlar om hur man kan tänka för att bestämma vilken avgränsning en modell ska ha.

Först går jag igenom ett par allmänna principer om hur man kan tänka när man avgränsar kontext för en modell. Sedan går jag igenom fyra typiska fall och ger några praktiska råd. Råden är liksom i de tidigare artiklarna om modelleringsstrategi delvis baserad på Eric Evans tankar om strategi ur boken ”Domain Driven Design”.

Allmänna principer: Hur smal eller bred ska en modells kontext vara?

En modell har alltid en viss kontext. Den kan vara bred eller smal. Men hur ska vi avgöra om vi ska göra en bred modell som täcker mycket, eller flera smala som var och en är avgränsad till ett delområde?

Observera att jag här menar modell och inte modelldiagram. Det är viktigt att vi inte blandar ihop detta. En modell kan ofta behöva delas upp i flera diagram, men det är likafullt samma modell, så länge den har samma avgränsade kontext och är konsistent inom detta.

Hur omfattande en modell ska vara är en bedömningsfråga som till stor del handlar om intuition, det vill säga kunskap som vi har men som vi inte riktigt kan utrycka på annat sätt än som vad som känns rätt. Men vi kan i varje fall peka ut några faktorer som talar för en bredare kontext, och andra som talar för en smalare.

Det som talar för en bredare kontext:

  • En verksamhetsprocess går smidigare att implementera när den hamnar inom en enhetlig modell. Det är lättare att greppa en modell än två olika, samt att vi då även måste hantera mappningen däremellan.
  • Översättningen mellan de olika modellerna kan bli svår (och ibland till och med omöjlig).
  • Ett gemensamt språk ger tydlig kommunikation.

Det som talar för en smalare kontext:

  • Modellen blir enklare, vilket medför att kommunikationen mellan personer blir enklare, så länge man håller sig inom modellens kontext.
  • Enklare modellering, ty bredare modeller behöver vanligen bli mer abstrakta för att täcka fler alternativ.
  • Den kontinuerliga integreringen blir enklare. En smalare kontext betyder färre direkta intressenter med mer likartade behov som man behöver täcka.
  • Med separata modeller för olika intressenter kan man bättre tillgodose specifika behov och även specifika jargonger hos specialiserade grupper.

Allmänna principer: Var dra gränsen mellan flera avgränsade kontexter?

Då man delar en domän till två separata modeller, det vill säga två olika avgränsade kontexter, är det viktigt var man placerar gränsen mellan modellerna. Målet är att beroendet mellan modellerna blir så litet, enkelt och tydligt som möjligt. Då behöver vissa modellelement hamna på samma sida om gränsen.

Det som talar för att två modellelement bör hamna i samma avgränsade kontext, det vill säga i samma modell är följande:

  • Elementen hör samman på ett naturligt sätt.
  • Elementen brukar ofta refereras tillsammans.
  • Elementen har många och djupa kopplingar till varandra. Särskilt om sambanden är dubbelriktade.
  • Informationen i de två elementen ägs av samma verksamhetsfunktion.

Observera att det här egentligen går tillbaka på mycket generella principer för hur vi ordnar saker i största allmänhet. De gäller för alla typer av avgränsningar vi gör och kan göra. Till exempel när vi placerar saker i olika byrålådor, eller hur vi sorterar dokument i olika mappar. Eller då vi delar en modell i olika ämnesområden, men det fortfarande ändå ser det som samma modell.

Ett sammanhang där jag som informationsarkitekt deltar är i systemutvecklingsprojekt. Då behöver vi i projektet bestämma vilka kontexter vårt projekt och därmed våra modeller ska ha. Varje avgränsad kontext blir normalt ett eget system eller delsystem.
Nedan går jag igenom fyra olika typiska fall.

Fall 1: Vi bygger ett nytt it-system som ska integrera mot ett äldre system

Den information som finns i ett äldre system måste ses som sin egen kontext eftersom systemet inte kan stöpas om bara sådär. Det vill säga att vi måste acceptera det äldre systemet som det är, med sina begrepp och strukturer, vare sig det passar vår egen kontext eller inte.

Men se upp med att äldre system ibland, i praktiken, kan inrymma fler än en avgränsad kontext. Ty en avgränsad kontext bestäms av att det hos de som utvecklar och förvaltar systemet finns en avsikt att hålla ihop modellen för systemet inom dess gränser. Om förvaltningsteamet för det äldre systemet inte kontinuerligt har integrerat sina olika uppdateringar av kodbasen, eller databasen, kan det finnas svåra semantiska motsägelser inom systemet. Då går det inte att hantera det äldre systemet som en enda väldefinierad och avgränsad kontext, utan måste kanske hanteras som flera.

Fall 2: Du ska designa ett nytt it-system

När ett helt nytt it-system ska utvecklas behöver du definiera ett eller flera avgränsade kontexter för domänen, och sedan tillämpa kontinuerlig integration inom dessa. Men vilka kontexter ska du ha, hur många ska det vara, och vilka relationer skall de ha till varandra?

Om kraven på funktionaliteten håller ihop väl, och projektet inte är för stort, räcker det med en enda avgränsad kontext för hela systemet.

Om projektet växer och det blir svårt att kontinuerligt integrera allt, bör du dela modellen i två. Du bryter då isär på så sätt att beroendet mellan delarna blir så litet och tydligt som möjligt. Vi får då två delsystem som kan (men strikt inte behöver) utvecklas och förvaltas av olika team.

Beroendet behöver helst också gå endast i ena riktningen, så att vi kan upprätta ett kund-leverantörsförhållande mellan delarna. Om vi inte kan undvika ett beroende som går i båda riktningarna behöver vi upprätta en delad kärna.

Du har nu två team med varsin avgränsad kontext. Då kan det hända att de två teamen tänker så olika att det ständigt blir problem med det som måste hanteras gemensamt. Det kan bero på att de verkligen behöver helt olika saker från modellen eller att de har så pass olika bakgrund att de ser olika på företeelserna. Det kan också bero på att teamen arbetar på olika sätt.

Om detta är något du inte kan eller vill göra något åt kan du välja att låta delsystemen och därmed modellerna att gå skilda vägar. Du kan då skapa ett översättningslager (translation layer) mellan de olika delsystemen. Detta kan då underhållas gemensamt av de båda grupperna.

Det måste alltid finnas ett uttalat team, och inte flera, som är ansvarigt för en avgränsad kontext. Ett team kan hantera fler än en avgränsad kontext, men det är svårt för flera team att dela på en och samma avgränsade kontext.

Fall 3: Du behöver ta hand om speciella behov med en särskild modell

Olika grupper inom samma verksamhet har ofta egna specialiserade terminologier som skiljer sig från varandra. Det kan bero på att de har olika bakgrunder eller behöver hantera olika specialiteter. Dessa lokala jargonger kan vara mycket precisa och skräddarsydda för just deras arbete. Om man vill införa en standardiserad terminologi som ska ersätta de lokala är det mycket krävande. Det kräver en djup förståelse som man kan få först efter lång tids arbete inom domänen, och dessutom diplomati och samverkan under lång tid. Även om man lyckas finns det risk att den nya terminologin inte fungerar lika bra som den egna exakt anpassade terminologin.

Ett alternativ är att i stället tillgodose det speciella behovet av en egen terminologi i en separat avgränsad kontext. Men det finns en risk att denna möjlighet kan bli ett argument mot förändring, och bidra till att behålla ett dåligt fungerande och inskränkt terminologi och synsätt. Hur värdefull är egentligen den egna jargongen för gruppen? Och hur kan jag veta vad som är värt att behålla och vad som kan förändras? Jag behöver vara ödmjuk, och försiktig med det som faktiskt fungerar.

Ibland växer det fram en djupare modell som kan ena de olika språken och tillgodose de olika grupperna. Haken är att en djup modell alltid uppstår sent i livscykeln, efter mycket utveckling och tänkande, om den uppstår alls. Du kan inte planera för en djup modell. Du kan bara vara öppen för att det kan hända, acceptera möjligheten när den dyker upp, och då ändra strategi och refaktorera.

Fall 4: Du kommer in i ett projekt som pågår

Ibland kommer du som informationsarkitekt in i ett projekt som har pågått ett tag. Då kan du inte bara ge dig på att ändra allting efter eget skön. Men du behöver ändå ta kontroll över situationen. Du kan lämpligen göra så här:

  1. Definiera avgränsade kontexter Det första du då bör göra är att identifiera och definiera avgränsade kontexter, som det förhåller sig nu, det vill säga hur teamet är organiserat idag. Detta är avgörande. Kontextkartan måste avspegla verkligheten som den är just nu, inte den ideala ordningen som du ser den. Förändringar måste alltid utgå från nuläget.
  2. Tajta upp teamets arbetssätt baserat på den befintliga organisationen. Försök inte ändra allt, utan utgå även här från hur det fungerar idag. Förändringar måste alltid ske i små steg, och man måste ha människorna med sig.
  3. Se över och förändra så småningom, vilka olika kontexter som systemet omfattar och hur de är avgränsade från varandra. Det vill säga om det behövs, vilket inte alltid är fallet.

/Peter Tallungs, IRM

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

Modellmönster: Temporala mönster

Hur kan vi hantera tidsuppgifter i våra informationsmodeller? Det är en av de vanligaste utmaningarna, och kan samtidigt vara det stökigaste man har att göra med, som modellerare. Välkommen in i världen av temporala mönster! Det handlar om hur vi kan organisera informationen så att man kan ställa frågor på ett enkelt sätt, utan att man för den sakens skull trasslar ihop sin modell fullständigt.

Ibland räcker det helt enkelt med att bara hålla reda på vad som gäller just nu, att registrera ett snapshot av verkligheten. Det är enkelt och okomplicerat. Saker blir dock lite mer intressanta när vi inte bara vill veta tillståndet av världen just nu, utan även tillståndet för sex månader sedan. Riktigt jobbigt kan det bli om vi behöver veta vad vi för två månader sedan trodde om tillståndet för sex månader sedan. Välkommen in i världen av temporala mönster! Det handlar om hur vi kan organisera informationen så att man kan ställa frågor på ett enkelt sätt, utan att man för den sakens skull trasslar ihop sin modell fullständigt.

Mönster 1: Audit log

Det absolut enklaste sättet att registrera förändringar i data är med en så kallad audit log som finns i alla databaser. En audit log registrerar alla förändringar i en tabell.

Fördelen med en sådan logg är att den finns där färdig att använda, i varje fall om du har en databas. En annan fördel är att den inte komplicerar de vanliga frågorna mot databasen, som handlar om läget just nu och inte hur det var historiskt. Nackdelen med en audit log är att när du verkligen behöver få fram historiska data kräver det en större ansträngning. Du behöver manuellt gräva i en loggfil.

Med andra ord är en audit log är användbar då man bara behöver komma åt historiska data ibland och att det då inte behöver gå snabbt och enkelt.

Mönster 2: Giltighet

Det vanligaste mönstret man brukar använda för att hantera tidsaspekten, utöver audit log, är att märka dataposter med Giltighet, vanligen som Från och med- och Till och med-datum. Eller datum och tid i de fall man behöver den upplösningen. Man märker posten med den tidsperiod den anses vara giltig för. När man sedan ska komma åt poster måste man alltid ange vilket datum (eller datum och tid) man är intresserad av för att komma åt rätt poster.

Fördelen är att det är en enkel mekanism, både att bygga och använda. Nackdelen är att klienten, människan eller programvaran som läser uppgiften behöver känna till, och parameterisera frågan med, vilken tidpunkt den är intresserad av. Detta behöver den göra i alla lägen även om den nästan alltid bara är intresserad av nuläget.

Idealet är att kunna gömma och glömma den temporala aspekten tills man behöver den. Det kan åstadkommas på två sätt. Man kan automatiskt och standardmässigt parameterisera varje åtkomstmetod med aktuellt datum för frågetillfället. Eller man kan ha en vy som automatiskt ger den post som gäller vid frågetillfället. De båda metoderna gör egentligen samma sak, de förutsätter att man vill ha det som gäller just nu om man inte explicit anger en annan tidpunkt.

Mönster 3: Version

Ofta vill man tänka på företeelser som att de förekommer i versioner över tid. Det kan exempelvis vara kontrakt som genomgår en serie ändringar över tid. Du vill ibland betrakta varje version av kontraktet som det verkliga kontraktet, vilket det ju faktiskt också rent formellt är.

I den mer praktiska vardagen vill du kanske se det som flera versioner av ett och samma kontrakt.

Mönstret ger på så sätt en och samma företeelse två olika roller, å ena sidan en kontinuerlig över tid, å andra sidan de enskilda versionerna som fångar tillståndet hos objektet för en viss period i tiden. Så snart någon egenskap hos objektet ändras så får man en ny version.

Det kontinuerliga objektet är det man refererar till då man tänker på objektet över tiden. Det har endast de egenskaper som inte kan förändras över tid, framförallt id-begrepp, men även andra essentiella egenskaper.

Mönstret bör användas när verksamheten ser på objektet som att det förekommer i versioner i någon form. Jag har jobbat i försäkringsvärlden i många år. Det vi kallar ”försäkring”, men rätteligen heter ”försäkringsavtal”, har just detta mönster med versioner. Varje version är rent juridiskt ett eget avtal, men för kunden är det ”min bilförsäkring”, det vill säga en och samma försäkring över tid. Och därmed är det även så för alla som arbetar mot kunden, vilket inbegriper i stort sett alla aspekter av verksamheten.

Problemet med två tidsdimensioner

Ofta har vi två olika tidpunkter för en händelse:

1.   Verklig tidpunkt, det vill säga när händelsen inträffade.

2.   Registreringtidpunkt, det vill säga när vi fick reda på att händelsen inträffade.

Därmed har vi två tidsdimensioner att ta hänsyn till, och därmed två olika historier för ett objekt eller en egenskap hos ett objekt. Låt mig visa med ett exempel.

Säg att min timlön har förändrats enligt tabellen.

Registrerat datumVerkligt datumTimlön kr
1 jan1 jan100
15 feb15 feb100
25 feb15 feb100
25 feb25 feb100
14 mar15 feb100
15 mar1 jan100
15 mar15 feb200
15 mar25 feb200
Den verkliga historiken

Låt oss först titta på den verkliga historiken. Min timlön var 100 kronor fram till den 15 februari då den ökade till 200 kronor. Det är den verkliga historiken så som den är känd (registrerad) den 15 mars.

Om vi i stället tittar på den verkliga historiken så som den var känd den 15 februari så var min lön 100 kronor i timmen och några 200 kronor var det aldrig tal om. Varje enskild dag i registreringshistoriken har således en egen verklig historik. Historiken ändras allt eftersom vi får reda på att det som var sant inte längre är sant.

Den registrerade historiken

Min lön för den 25 februari var registrerad som 100 kronor fram till den 15 mars då den blev registrerad som 200 kronor. Registreringshistoriken talar om hur vår kunskap om en viss dag förändras. Varje dag i den verkliga historiken har på så sätt en egen registrerad historik.

Det här var väl inte så krångligt, tänker du kanske. Men vänta bara…

Registrerat datum Verkligt datum Timlön kr
1 jan1 jan100
15 feb15 feb100
25 feb15 feb100
25 feb25 feb100
14 mar15 feb100
15 mar1 jan100
15 mar15 feb200
15 mar25 feb200
26 mar25 feb200
4 apr1 jan100
4 apr14 feb100
4 apr15 feb250
4 apr25 feb250

Tänk att vi den 4 april får en korrigering som säger att lönen den 15 februari i stället höjdes till 250 kronor.

Det är sånt här som får en analytiker att vilja dunka huvudet i väggen! Men låt oss se hur man kan förstå det hela.

Om vi återigen tar fasta att vi har att göra med två olika tidsdimensioner så brukar det klarna för mig.

Den verkliga historiken, som den är registrerad den 4 april, säger att min timlön var 100 kronor från den 1 januari och höjdes till 250 kronor den 15 februari. En lön på 200 kronor förekom aldrig, för den var inte sann.  

Den registrerade historiken säger att timlönen för den 25 februari var 100 kronor och att den höjdes till 200 kronor den 15 mars.

Hur kan vi hantera detta? Låt oss titta på några modellmönster för att hantera situationer med två parallella tidsdimensioner.

Mönster 4: Både verkligt och registrerat datum i audit log

Ett sätt att göra det enkelt för sig är att helt enkelt logga alla ändringar i audit log och överlåta problemet till den som vill läsa ut och analysera tidsförloppet. Det är rätt lösning i det fall att det är sällan annat än aktuell lön är intressant.

Mönster 5: Verklig tid-modellen

Vi hanterar bara verklig tid i modellen. För de fall vi bara är intresserade av hur saker och ting har ändrats över tiden i verkligheten men inte bryr oss om när vi fick kunskap om händelserna. Det är rätt val i många fall, till exempel för en kunds adress.

Mönster 6: Registrerad tid-modellen

Vi hanterar bara registrerad tid i modellen. För de fall då själva registreringen är en händelse som styr annat och därmed är viktig att hålla reda på.

Exempel: Vi skapar fakturor automatiskt baserade på tillstånd hos objekt. Det är då viktigt att kunna spåra hur en faktura beräknats. Vi behöver därför hålla reda på vad vi trodde om ett tillstånd vid den tidpunkten då fakturan producerades.

Ett alternativ är att i stället lagra alla de argument som användes när fakturan beräknades, tillsammans med fakturan.

Mönster 7: Bi-temporala-modellen

Den fulla lösningen med båda tids-dimensionerna. Den behövs sällan.

Problemet med uppdatering av temporala poster är att det är stökigt att tillåta ändring av temporala poster, exempelvis en post som säger att en anställd har en lön från ett visst datum. En ändring kan omfatta varje möjlig kombination av startdatum, slutdatum och lön. Ett gränssnitt för detta kräver många regler som styr vad som går att göra och vad det får för effekter. Vi behöver därför förenkla. Låt oss titta på två mönster för detta.

Mönster 8: Tillåt endast tillägg av poster, ej borttag eller ändringar

Alla ändringar hanteras som tillägg eller som en kombination av tillägg.

Mönster 9: Tillåt endast uppdateringar som gäller från och med idag

De enda uppdateringar som tillåts är de som gäller från och med idag. Retroaktiva uppdateringar tillåts inte. 

Som sagt, detta är ett jobbigt område. Det kan vi inte komma ifrån. Men jag hoppas att vi genom dessa mönster har fått lite bättre grepp om vilka alternativ som står till buds.

Även i denna artikel har jag inspirerats från vad jag hittat i Martin Fowlers bok ”Analysis Patterns” från 1997. Boken är, som jag nu flera gånger tjatat om, en dold skatt vad gäller modellmönster för oss informationsmodellerare.

Det här var sista artikeln om modellmönster, åtminstone för nu. Men kanske har du några modelleringsproblem som du skulle vilja belysa, eller något mönster som du brukar använda jag vi inte tagit upp. Låt höra i så fall.

Nästa artikel handlar om informationsarkitekten, vad rollen kan innehålla och inte innehålla. Vi bjöd in till en frukostträff den 15 oktober i år, där vi diskuterade ämnet. Vi röstade då på ett antal möjliga omfattningar för rollen. Jag kommer att presentera resultatet från röstningen och även försöka mig på en analys av detta.

/Peter Tallungs, IRM

Nästa artikel i serien publiceras torsdag 4 november. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Modellmönster: Planering

De flesta organisationer behöver planera sin verksamhet samt följa upp planerna. Till detta har de diverse informationssystem. I detta sammanhang finns det lite mer att tänka på än man kanske till förstone tror.

I denna artikel tar jag avstamp i det enklaste och vanligaste mönstret, Planerad – Pågående – Genomförd, och förklarar varför det inte alltid fungerar så bra. Jag ger i de senare mönstren i artikeln ett alternativt sätt att se på planer.

nster 1: Uppgift

Beståndsdelarna i en plan är de uppgifter som vi människor planerar och genomför. En uppgift kan definieras som en avgränsad enhet av arbete som man planerat att göra, gör just nu eller har gjort. En uppgift kan ha ett antal egenskaper baserat på vem, vad, var och när.

Mönster 2: Planerad – Pågående – Genomförd

När vi gör planer och när vi övervakar planer behöver vi ta hänsyn till de tillstånd en uppgift kan ha. Det är vanligt att man har tillstånden Planerad, Pågående och Genomförd, eller motsvarande.

Det här är ett enkelt och mycket vanligt mönster, som kan verka naturligt och självklart. Men Martin Fowler argumenterar i sin bok ”Analysis Patterns” för att mönstret egentligen inte är särskilt realistisk, det vill säga att den är en teoretisk modell som rimmar dåligt med hur vi gör i verkligheten.

Låt oss titta närmare på svagheterna med detta mönster.

Planering kan sägas bestå av tidsplanering och resursplanering. Dessa kan ske i vilken ordning som helst. Men många uppgifter sätts igång utan formella beslut. De har då varken tids- eller resursplanerats. Vi kan ju förstås alltid hävda att de planeras precis i det ögonblick de startas, men det blir då mer en teoretisk styrmodell än en korrekt bild av verkligheten. Ett annat problem med detta enkla mönster är att det inte tar höjd för att många aktiviteter sätts igång innan man har alla resurser som kommer att behövas. Man planerar att anskaffa det som behövs under vägen.

Hur ska vi då göra? Jo, antingen kan vi söka ett mönster som bättre avspeglar verkligheten. Eller så kan vi använda detta enkla linjära mönster. Men då bör vi i alla fall känna till och närmare förstå dess svagheter. I annat fall får vi svårt att hantera svagheterna när de ger sig till känna.

Mönster 3: Föreslagen uppgift och Implementerad uppgift

Ett helt annat sätt att se på uppgifter, ett sätt som enligt min mening stämmer bättre med verkligheten, är att de finns som två olika företeelser, Föreslagen uppgift och Implementerad uppgift.

En föreslagen uppgift finns bara i en plan som ett förslag. Där kan den resurs- och tidsplaneras i godtycklig ordning. Uppgiften har ingen verklig existens. Först om och när den påbörjas får den en verklig existens, den är då implementerad, det vill säga att uppgiften pågår eller är redan genomförd. Vi bör då se den implementerade uppgiften som en helt egen företeelse, och inte som en föreslagen uppgift som ändrat tillstånd.

Det gör att vi kan registrera skillnader mellan plan och genomförande. Skillnad i tid sker nästan utan undantag, men egentligen kan precis alla egenskaper ändras från plan till genomförande. För att få flexibilitet bör länken mellan föreslagen och implementerad uppgift vara icke-obligatorisk.

Planering är viktigt, men planen är bara en hypotes som snabbt kan bli överspelad. När verkligheten träffar våra planer blir ibland även de bästa planerna lagda på hyllan, och många andra saker händer utan att vara planerade.

En allmän reflektion är följande: Det som vi i förstone ser som två olika tillstånd hos en och samma företeelse, kan ibland förstås bättre som om vi ser det som separata företeelser med olika identiteter och egenskaper.

Frågorna man kritiskt bör ställa sig är följande:

  1. Följer tillstånden regelmässigt på varandra, inte bara i vår ideala föreställningsvärld utan även i verkligheten?
  2. Förblir de väsentliga egenskaperna desamma före och efter tillståndsövergången?
  3. Är det sällsynt att en företeelse i första tillståndet splittras i flera företeelser i andra tillståndet (som att en planerad uppgift implementeras som flera uppgifter), eller tvärtom, att flera företeelser i första tillståndet slås samman till en enda företeelse i andra tillståndet (som att flera planerade uppgifter genomförs som en uppgift)?

Mönster 4: Genomförd uppgift och Annullerad uppgift

Så här långt har vi undersökt hur uppgifter föreslås och hur de påbörjas, men ännu inte om de genomförs.

Ett problem är att vi i många sammanhang inte kan säga med säkerhet om en uppgift var en framgång eller ett misslyckande. Det är ofta endast en subjektiv bedömning, och kan kanske göras först långt i efterhand.

Därför tar vi i detta mönster bara med två möjliga utgångar: avslut eller nedläggning, det vill säga vi får Genomförd uppgift och Annullerad uppgift. Observera att faktat att en uppgift är genomförd inte säger något om resultatet, det vill säga om den lyckades eller misslyckades.

Besltet om att annullera en uppgift kan komma antingen före eller efter att den påbörjats. Att annullera en föreslagen uppgift är detsamma som att besluta att inte påbörja.


Mönster 5: Suspension

Vi kan pausa en uppgift med avsikt att fortsätta den senare. Tisperioden för suspensionen kan ha en öppen sluttid, vi vet inte hur länge en pågående paus kommer att vara.

Om supensionens sluttiden är passerad är den inte längre suspenderad utan aktiv. En uppgift är suspenderad om den har en för ögonblicket gällande Suspension.

Både föreslagna och implementerade uppgifter kan vara suspenderade. Att suspendera en föreslagen uppgift är samma som att senarelägga starten.


Mönster 6: Plan

En Plan är i sin enklaste form en samling uppgifter länkade i någon slags sekvens. Sekvensen uttrycker vanligen någon form av beroende, att en uppgift inte kan påbörjas förrän en annan är slutförd.


Mönster 7: Interagerar planer

I många situationer samverkar eller interagerar flera planer med varandra. En och samma uppgift ingår i flera planer. Ett beroende mellan två uppgifter gäller endast inom en viss plan.

Var kommer dess mönster ifrån?

Dessa mönster härstammar från Martin Fowlers bok ”Analysis Patterns”. Som jag tidigare har skrivit är det en orättvist bortglömd skatt, som jag gärna vill lyfta fram.

/Peter Tallungs, IRM

Modellmönster: Produkt – del 1: Produktstrukturer

De flesta verksamheter erbjuder sina kunder produkter eller tjänster av något slag. Runt produkter och tjänster finns det många företeelser som behöver modelleras, definieras och benämnas. Ämnesområdet Produkt är i en del verksamheter så centralt att det finns informationsmodellerare som kallar sig för produktmodellerare. Jag går i denna, och följande, artikel igenom några centrala begrepp och mönster inom produktområdet.

Produkt eller tjänst?

Termen ”produkt” kan stå för olika saker. Det gemensamma är att det är något som en verksamhet kan tillhandahålla till sina kunder. I den ursprungliga betydelsen är det något materiellt, till skillnad från tjänst som är den immateriella motsvarigheten. Men det har blivit vanligt att man benämner även tjänster som produkter. Och eftersom de mönster jag kommer presenterar här fungerar lika bra för materiella som immateriella produkter så gör jag här ingen skillnad.

Verksamheter har ofta problem med sin produktflora

Jag upplever att man i många verksamheter har problem med en oöverskådlig produktflora och svårt att ens komma igång med att bringa ordning. Man har ofta stupat redan på tröskeln, redan när man försökt bestämma vad en ”produkt” är. Kanske har man ett par tusen saker registrerade som man säljer, men frågan blir då: Är det verkligen produkter? En del varor man erbjuder är kanske paketeringar av flera olika produkter. Och andra företeelser man hanterar är kanske bara komponenter som man sätter ihop produkter av. Många produkter är så lika varandra så man kanske borde se dem som varianter av en och samma produkt. Och några är små förbättringar av tidigare produkter, så man kanske borde se dem som versioner av en och samma produkt. Hur kan man bestämma vad som är vad, och hur ska man hålla reda på det?

Det brukar bli många åsikter, och jag har upplevt att många verksamheter inte har kunnat reda ut detta. Man har helt enkelt gett upp alla försök att bringa ordning i produktfloran, med resultatet att det blivit svårt att analysera och följa produkters beteenden över tid.

Men det är egentligen inte så svårt. Vi bör bara vässa våra analysverktyg en smula och gå metodiskt tillväga, begrepp för begrepp. Där har vi informationsarkitekter en viktig uppgift att fylla.

Om begreppet ”produkt”

Ett fruktbart sätt att se på begreppet produkt är att det är någonting man kan erbjuda kunder som en enhet.

”Kan erbjuda” är viktigt för det är en produkt, även om det är något man ännu inte har erbjudit någon kund. Eller av olika omständigheter aldrig kommer att erbjuda en kund.

Jag vill inte skriva ”sälja” för jag tycker inte att det är någon egentlig skillnad i avseendet om eller hur vi får ersättning för det vi erbjuder. En produkt kan vara helt gratis, det är likafullt en produkt.

”Som en enhet” är viktigt, ty mycket av det vi kan erbjuda kan vi inte erbjuda i sig självt utan bara som en komponent av något annat. Om jag säljer bilar så erbjuder jag kanske röd lack. Men inte som en självständig enhet. Du kan inte köpa röd lack av mig utan att den sitter på en bil. Du kan bara få röd lack som en komponent till bilen du köper. Men jag vill ju kanske ändå kunna följa upp hur röd lack säljer.

Det betyder inte att jag alltid måste sälja en produkt som en egen enhet. Jag kan paketera flera produkter så att de tillsammans blir en paketering. Du kanske kan köpa ett paket av mig med en isskrapa plus rattmuff. Det avgörande för om det är en produkt är att jag kan erbjuda den för sig själv.

Men ”produkt” är långt ifrån det enda begreppet vi behöver definiera. Låt oss gå vidare. Det har för övrigt ingen betydelse om man benämner produkt för ”artikel” eller ”vara”. Frågeställningarna och lösningarna blir precis desamma.

Mönster 1: Produktindivid

Vi behöver begreppsmässigt skilja de individuella exemplaren av en produkt från det som vi i förra stycket kallade för produkt. Ett namn som förekommer är ”produktindivid”, ”produktförekomst”, ”produktinstans” eller ”produktexemplar”.

Det kan finnas noll, en eller flera produktindivider av en och samma produkt. En produktindivid är alltid en individ av en viss produkt och har ett existentiellt beroende till denna, som jag uttrycker med en romb i änden på relationslinjen. Det uttrycker att produktindividen inte kan existera oberoende av sin produkt och att den heller aldrig kan ändras så den blir en individ av en annan produkt.

Produkt ligger i ett regelplan i förhållande till produktindivid, vilket betyder att när vi lägger upp en ny produkt kan det i detta sammanhang ses som en konfigurering av verksamheten. Vi bestämmer vad vi kan erbjuda. Det har inte hänt något operativt bara för att vi lägger upp en ny produkt, vi har inte producerat något, det betyder bara att vi bestämt att det finns ett visst erbjudande. Det är inte förrän det skapas ett exemplar av den produkten, en produktindivid, som det händer något operativt, som någon form av produktion har skett.

Resonemanget är precis lika för tjänster, det vill säga immateriella produkter. Ett försäkringsbolag erbjuder dig en hemförsäkring (produkt). Du tecknar en sådan, och avtalet får ett försäkringsnummer (en produktindivid). Den enda skillnaden är att en immateriell produkt (tjänst) uppstår genom någon form av performativ (utförande) akt.

Mönster 2: Produkttyp

Man delar vanligen in produkter efter olika kriterier i produkttyper, produktgrupper etcetera. Jag har inte tagit med det i diagrammet. Om vi fokuserar på själva produktadministrationen som en verksamhetsförmåga kommer man kanske vilja se entiteten produkt som tillhörande ett operativt plan. När man definierar en ny produkt innebär det just i detta sammanhang en operativ handling. Hur man delar in sin produktkatalog i produkttyper och produktgrupper innebär med det perspektivet att man konfigurerar verksamheten i fråga.

Med detta vill jag bara visa att vad man ser som operativt är inget absolut utan beror på sammanhanget. Att något sådant kan hända vid ett perspektivskifte kan kännas flyktigt och osäkert för en del. Men jag anser att det är viktigt att veta att olika kontext ger olika perspektiv och att vilken kontext man har kan därmed vara avgörande för modellen.   

Observera att jag här har valt att Produkt inte har ett existentiellt beroende till Produkttyp (det vill säga ingen romb i änden). Jag ser produkttyp som något som vanligen är en ganska flyktig indelning av produkter. Man kan ju ofta ändra typningen av produkter, det vill säga hur man delar in produkter i olika produkttyper, utan att det därför blir nya produkter. Man kan förstås hävda motsatsen för sin specifika verksamhet, men jag tror det är ovanligt. Det här är en bedömning jag gör, och det kan variera från verksamhet till verksamhet. Den kritiska frågan är: Kan en produkt ändra produkttyp och ändå ses som samma produkt. Om svaret är ja: ingen romb, om svaret är nej: romb.

Mönster 3: Produktvariant

En produkt kan finnas i flera varianter. Det kan vara olika färger eller andra smärre skillnader, men att man ändå vill se det som en och samma produkt. Vad som är olika produkter och vad som är flera varianter av samma produkt är ett val man gör i verksamheten.

Jag har varit med om att någon i en verksamhet har sagt att de egentligen har bara en produkt, men vi levererar den i många varianter, medan någon annan vill se det som att man har väldigt många produkter. Man behöver komma fram till hur man vill se det och vilka egenskaper som ska skilja för att man ska betrakta två artiklar som varianter av samma produkt. Det har mycket med marknadsföring och försäljning att göra, det vill säga hur man vill presentera varorna för kunderna.

Det finns alltid minst en variant av varje produkt. En produktindivid blir alltid en förekomst av en specifik produktvariant.

Mönster 4: Produktvarianttyp

Det finns ofta ett behov av att kategorisera även produktvarianterna. Om man säljer till exempel hushållsapparater kan det vara färger eller elanslutning. Det finns 14 olika standarder för elkontakter världen över. I vissa verksamheter har varje produkttyp sina egna varianttyper, i andra kan de vara gemensamma tvärs över hela produktkatalogen.

Mönster 5: Produktversion

Produkter förändras över tid. Man behöver hålla reda på vilken version en produktindivid är av. Inte bara produkter har versioner utan även produktvarianter. På så sätt får vi två parallella stråk i vår produktstruktur. En som är mer beständig över tid, och en annan som fångar hur en och samma produkt utvecklas över tiden.

Men hur bestämmer man när en viss vara ska ses som en ny produkt eller en ny version av en befintlig produkt? frågar sig den skarpsinnige. En riktlinje brukar vara att om ändringen är så pass framträdande att kunden uppfattar det som en ny produkt ska det vara en ny produkt annars är det en endast en ny version av den befintliga. Ett klädföretag jag jobbade för sa så här: ”Om en söm inte visar sig hålla i längden åtgärdar vi det. Då blir det en ny version. Kunden märker inte detta vid köpet, men vi vill veta vilken version en viss produktindivid är av när vi får klagomål. Om det visar sig att en ficka sitter fel placerad på en skjorta, och vi åtgärdar det, då blir det en ny produkt för kunden ser skillnaden.”

Mönster 6: Produktkomponent

Ofta utvecklar man komponenter som man kan använda för att bygga ihop olika produkter. En komponent kan definitionsmässigt inte säljas separat som en egen enhet, i så fall skulle den vara en produkt i sin egen rätt. Komponenter används inte bara i materiella produkter. Försäkringsbolag och finansiella verksamheter har ofta ett antal produktkomponenter vilka används till olika produkter.

Observera hur jag namnger och definierar den entitet som utgör många-till-många-relationen ”Produktkomponent i produktvariant”. Jag tycker att det är viktigt att vara strikt med att namnet, och definitionen avser en förekomst av entiteten. Det gör det lättare att förstå vad entiteten representerar. Man ser annars ofta att entiteten kallas Produktkonfiguration, men jag tycker att man bör vara konsekvent med att namnet på en entitet alltid ska vara namnet på en förekomst av entiteten. En förekomst av den entiteten är inte en fullständig konfiguration av en produkt utan endast en detalj av konfigurationen, nämligen just faktumet att en viss komponent används i en viss produktvariant.

Produktkomponenter har i likhet med produkter och produktvarianter sina typer, varianter och individer. Kanske behöver man också hålla reda på vilken version av en produktkomponent som ingår i en viss version av en produktvariant, och även vilken komponentindivid som ingår i vilken produktindivid.

Jag har i diagrammet tagit med följande:

  • Produktkonfigureringar på typnivå, det vill säga vilka typer av produktkomponenter som kan förekomma i vilka typer av produktvarianter.
  • Produktkonfigureringar på variantnivå, det vill säga vilka produktkomponenter som kan förekommer i vilka produkter.
  • Produktkonfigureringar på versionsnivå, det vill säga vilka versioner av komponenter som används i vilka versioner av produkter.
  • Produktkonfigureringar på individnivå, det vill säga vilket specifikt exemplar av en komponent som förekommer i vilket specifikt produktexemplar.

Layouten har stor betydelse

Lägg märke till den layout jag givit diagrammet, med entiteter i kolumner och rader. Själva strukturen och hur entiteterna är placerade i förhållande till varandra har stor betydelse då det skapar ordning och reda i begreppen och tankegången. Skillnaden mot om man placerar rutorna utan någon speciell tanke är helt avgörande för begripligheten.

Jag planerar att i senare artiklar ta upp sådant som gestaltning av modeller, hur man kan rita (och skriva) sina modeller på ett tydligare sätt så att de blir mer användbara.

/Peter Tallungs, IRM 

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

Modellmönster: Kundlivscykel – del 1: Kundstatus

Kunder kommer och kunder lämnar. En kund kanske börjar som prospekt, blir sedan en aktuell kund för att senare lämna av någon orsak. Kunder har alltså en livscykel, med tillstånd och händelser. Om vi skapar en modell för denna livscykel, med namngivna och definierade tillstånd och händelser, öppnar sig många möjligheter till att analysera rörelserna i kundstocken.

Hur det brukar se ut

Vanligen har man i ett kundsystem ett fält för status. Där kan det finnas en kod för om kunden är ett prospekt (det vill säga någon person eller organisation som man registrerat för att man aktivt vill bearbeta denne för att bli en kund) eller en riktig kund (det vill säga en som köper ens varor eller tjänster). Vanligen har man även en kod för om kunden är avslutad. Fast det är ofta oklart hur lång tid en kund ska avstå från att köpa något för att betraktas som avslutad. Vanligen har man olika uppsättningar av koder i olika system och ofta är inte tillstånden väldefinierade.

Det är också vanligt att man blandat in flera betydelser i samma fält. Till exempel kan man ha en kod för att kunden är avslutad på egen begäran och en annan kod för om kunden är avslutad för att den inte betalt sina skulder. Det vill säga att ett och samma fält har två betydelser, dels status (att kunden är avslutad) och dels orsaken till att kunden är avslutad. 

I avsaknad av en gemensam modell med gemensamma definierade begrepp så blir det besvärligt att göra analyser av rörelserna i kundstocken, eller att ens säga hur många kunder man egentligen har. Något som varit bland det första jag ofta fått höra i de verksamheter jag kommit till är just: ”Vi vet inte ens hur många kunder vi har!”.

Hur kan man göra?

Det första man behöver göra är att skapa en gemensam modell för kundlivscykeln. Sedan kan man mappa alla de lokala koderna i de olika kundsystemen mot denna. Eller egentligen är det ju tvärtom man gör. Man går igenom och analyserar de olika statuskoderna som finns i källsystemen och vilka kunder som har vilken kod och varför. Med den direkta kunskapen vi då får om verksamheten kan vi skapa en gemensam modell som blir det gemensamma språket för hela verksamheten. Sedan låter man de olika källsystemen rapportera status och händelser, till exempel till ett Data Warehouse, för sina kunder enligt denna modell. På så sätt får man möjlighet till gemensamma rapporter som kan jämföras med varandra. Och detta utan att man behöver ensa hela verksamheten i alla sina delar samtidigt. Med tiden kommer de olika delarna av verksamheten att gravitera mot det gemensamma synsättet, fast varje del i sin egen takt. Om det inte händer så har vi förmodligen de facto ett lokalt behov som inte tillgodoses av den gemensamma modellen. Vad bra då att vi inte tvingade på varje hörn av verksamheten den gemensamma modellen. Det är så vi på samma gång kan få ett gemensamt språk och ändå kan låta varje del ha sina egenheter anpassade för de lokala behoven. 

I diagrammet visas hur en informationsmodell för en kundlivscykel kan se ut.

I det följande kommenterar jag modellen, hur de olika begreppen är definierade, namngivna och gestaltade.

Om status, även kallat tillstånd: Först behöver vi diskutera detta med status. Vad innebär en status egentligen? Med status menar vi ett tillstånd ett objekt (en förekomst av något) kan befinna sig i. För att vara ett tillstånd ska det vara definierat av ett visst beteende, det vill säga att tillståndet bestämmer vad det går att göra med objektet. Ett exempel: En aktuell kund kan vi sälja något till, men ett prospekt måste vi kanske först göra till kund för att kunna sälja till. En aktuell kund kan vi avsluta, men en avslutad kund kan vi inte avsluta igen.

Vi bör inte kontaminera våra tillstånd med att definiera dessa utifrån händelsen eller orsaken som gjorde att objektet nådde det tillståndet. Ett exempel: En avslutad kund kan vara avslutad av många olika orsaker. Men beteendet, det vill säga vad man kan göra med en avslutad kund, är precis detsamma oavsett orsaken till att kunden är avslutad. Vi vill förmodligen hålla reda på orsaken till att en kund avslutats men det blir fel om vi skapar en specifik status för varje orsak. Jag visar i nästa artikel hur man kan hålla reda på orsaken.

Om begreppet Kund: I dagligt tal menar man med begreppet Kund någon som just idag är kund. Men jag menar att det blir mer praktiskt om vi utökar begreppet och även inkluderar prospekt och tidigare kunder. Vi behöver ju ett begrepp för den intressent som gör hela resan, från prospekt (en som är en kandidat till att bli kund i en nära framtid, via aktuell kund (en som är kund i egentlig mening just nu) till avslutad kund. Jag tycker att det är mest praktiskt att kalla alla dessa för kunder, även om det avviker från dagligt språkbruk. Ty det finns inget annat namn som är användbart vad jag förstår.

Om tillståndet ”Aktuell”: Ofta kallar man detta tillstånd för ”Aktiv”, men min erfarenhet är att det kan bli ett problem med det namnet i många verksamheter. En kund som vi har en aktuell kundrelation till kan ju vara mer eller mindre aktiv över tiden. I perioder handlar kunden ofta och i perioder är kunden frånvarande. Det vill man ofta följa. Till exempel kanske man vill ”väcka” kunder som inte varit aktiva på ett tag, genom en riktad kampanj.

Om kunden har uteblivit under lång tid vill vi förmodligen se det som att vi förlorat kunden. Men huruvida kunden just nu är aktiv eller inte är ändå inte samma sak som om vi ser kunden som aktuell. Därför föredrar jag termen ”aktuell”. (I brist på bättre får jag väl säga. Du kanske har ett bättre förslag?).

Om att skriva definitioner i entitetsrutorna: Jag gillar att skriva definitionen av en entitet i själva diagrammet under namnet. Det är ett enkelt sätt att öka chansen till att läsaren direkt förstår vad som företeelsen står för.

Om definitionen för entiteten Kundstatus: Observera att definitionen för Kundstatus är ”Status som en kund kan ha”. Det för att inte blanda ihop det med den status som en kund verkligen har, som ju betecknas av attributet Kundstatus i Kund och relationen från Kund till Kundstatus. En förekomst av entiteten Kundstatus är ju en status en kund kan ha, och säger inget om hur många, om ens någon, som har denna status.

Om redundans i modellen för attributet/relationen Kundstatus: Attributet Kundstatus hos Kund och relationen från Kund till entiteten kundstatus står ju båda för samma sak och är därmed redundanta. En del tycker att det är fel att i informationsmodellen ha med en och samma sak två gånger. Det har jag också tyckt en gång men har med tiden vägt över till att jag alltid tar med det attribut (eller i vissa fall de attribut) som manifesterar relationen. Jag har flera skäl till detta:

  1. Jag vill se även relationer som attribut, för det är de i all väsentlighet. Till exempel Kundstatus är en egenskap hos en kund, det vill säga ett attribut. Att värdeförrådet finns uppräknat i en annan entitet ändrar inte detta. När jag i text dokumenterar attribut och relationer finns det ingen skillnad. Alla relationer behöver definieras, beskrivas och dokumenteras på samma sätt som attribut som inte är relationer.
  2. Spårbarheten blir tydligare om man sedan ska realisera modellen, som till exempel en databas. För då blir det ju databaskolumner, och jag vill gärna att det ska finnas en så direkt koppling som möjligt mellan informationsmodellen och databasen.
  3. I informationsmodellen vill jag gärna markera vad som unikt identifierar en förekomst, eftersom det hjälper läsaren att förstå vad en entitet egentligen är. Då måste jag ha med de attribut som ingår i en kompositnyckel, även om de är nycklar till andra entiteter och sålunda manifesterar relationer.

Om att redovisa förekomsterna av till exempel Kundstatus: Det är inte bara entiteter, attribut och relationer som vi behöver namnge och definiera. Då det gäller attribut med ett antal definierade förekomster (som i exemplet Kundstatus) så behöver vi namnge och definiera varje förekomst. Det rör sig ju i stort sett alltid om centrala verksamhetsbegrepp som används i rapporter och analyser. Det är ett vanligt missförstånd att det räcker med att definiera och dokumentera entiteter, attribut och relationer. Men förekomster av detta slag är minst lika viktiga, men nästan alltid ignorerade. 

Det som behövs dokumenteras för varje förekomst är i regel en kod, eller ett kortnamn, ett namn och en definition. Det kan också behövas ett ordningsnummer för att visa förekomsterna i en logisk och återkommande sorteringsordning i en valbar ruta eller i en rapport. Vi kan även behöva giltigt från och med- samt till och med-datum, om vi kommer att behöva hantera förändringar.

Jag dokumenterar förekomsterna i textdelen av modellen, med tar vanligen med dem även i diagrammen. Det underlättar förståelsen av diagrammet avsevärt. Jag ser till att de rutor i diagrammet där förekomsterna listas skiljs ut tydligt från entitetsrutorna.

Om kod, för till exempel Kundstatus: Förr var det så att alla värden för en status (ett tillstånd) hade en kod. Det var så vanligt att den entitet som jag i modellen ovan kallar för Kundstatus, skulle många kallat för Kundstatuskod. Skälet till att man hade koder var att man behövde snåla med utrymmet i databaser och därmed behövde använda så få tecken som möjligt. Men idag finns inte just den begränsningen. Men det är ändå så att vi ofta behöver ett kort namn (vare sig man nu ser det som en kod eller ett kortnamn, gränsen är flytande) för saker och ting, speciellt då man ska visa saker i kolumner i en rapport eller dylikt. Så jag är kluven. I varje fall behöver vi någon form av kod eller kortnamn, kanske både och. Ibland ett maximalt kompakt (bara ett tecken), ett kort (tre eller fyra tecken) och ett fullt utskrivet namn.

Om tillståndsdiagram i informationsmodellen: Jag har alltid med tillståndsdiagram (Harel statechart eller state machine) i diagramdelen till min modell, som visat ovan. Men observera att tillståndsdiagrammet i det exemplet är ofullständigt. Kunder tar inte alltid den raka vägen. Somliga blir kunder utan att först vara prospekt. Somliga som är avslutade återkommer och så vidare. Jag kommer i nästa artikel komplettera tillståndsdiagrammet och även hantera händelser och händelseorsaker.

Till dess skulle det vara roligt att höra dina synpunkter och erfarenheter. Vad håller du med om och vad skulle du vilja göra annorlunda?

/Peter Tallungs, IRM 

Modellmönster: Ansvarsförhållanden mellan parter

I en verksamhet behöver man hantera olika typer av ansvarsförhållanden mellan parter. De man kanske först tänker på är de som uttrycks i organisationshierarkier, men det är bara ett av en mängd olika slag av ansvarsförhållanden. I denna artikel beskriver jag några användbara mönster för att hantera förhållanden där en part har ett ansvar gentemot en annan. Jag passar också på att ta upp hur man kan införa ett regelplan i sin modell. Det är ett effektivt sätt att göra sin informationsmodell tydligare.

Mönster 1: Organisationshierarki med explicita nivåer

Det här är ett vanligt och naturligt sätt att modellera organisationshierarkier, liksom hierarkier i övrigt. Varje typ av organisationsenhet har sin egen entitet. Det har sin stora fördel i att det känns naturligt, det vill säga överensstämmer med den bild vi har naturligt i huvudet. Men det har en begränsning. Om organisationsstrukturen ändras – om till exempel nivån med avdelningar tas bort för att platta till strukturen – måste vi bygga om modellen helt och hållet.

Mönstret ger alltså en tydlig och naturlig men inte speciellt flexibel modell.
Det räcker till i de fall vi inte behöver hantera historik, det vill säga hur organisationen förändras över tid.

Mönstret passar inte heller då vi behöver en mer generisk modell som ska användas för flera olika organisationer.

Mönster 2: Organisationshierarki med generaliserade organisationsenheter

Vi kan skapa en mer generell entitet som gäller för alla organisationsenheter oavsett typ. Vi kan sedan ha mer dynamiska regler för vilka subtyper som finns samt begränsningsregler för hur de kan relatera till varandra.

Detta mönster har möjligen en något större flexibilitet än föregående, det vill säga att det blir lite lättare att förändra organisationsstrukturen. Men vad vi nu vunnit i flexibilitet har vi förlorat i tydlighet.

Mönster 3: Flera organisationshierarkier

Ofta har man två eller flera parallella organisationshierarkier, det vill säga multipla rapportvägar. Det avbildar man på enklaste sätt genom att ha fler än en moder-dotter-relation.

(Subtyper och begränsningsregler har inte tagits med i diagrammet här).

Men om vi vill hantera egenskaper hos själva relationen, till exempel historik som vilken tidsperiod relationen gällde för, behöver vi lyfta själva relationen till att representeras av en egen entitet. Vilket tar oss till nästa mönster.

Mönster 4: Organisationshierarki med relationsobjekt

Vi kan göra själva relationen till en egen entitet. Då öppnas flera möjligheter:

  1. Nya typer av ansvarsrelationer kan lätt läggas till.
    Vi kan typa relationerna så att en organisationsenhet kan ingå i flera hierarkier samtidigt. Man kan till exempel ha en organisationshierarki baserad på produkt och en annan baserad på säljorganisation.

    Om vi endast har två hierarkier är detta knappt värt besväret, men för fler hierarkier än så är det användbart.
  2. Vi kan ge varje relation en tidsperiod då den gäller.
    På så sätt kan vi hantera förändringar över tid, till exempel att en enhet byter plats i strukturen.

    När man på detta sätt gör entitetstrukturen mera generell blir det viktigt att i text uttrycka de regler som begränsar vilka relationer som är möjliga. Observera att reglerna i detta fall läggs på själva relationen.

Vi kan använda detta som en metamodell vilken kan härbärgera alla möjliga ansvarsstrukturer mellan organisationsenheter.  

Mönster 5: Relationsobjekt för ansvarsförhållanden för olika typer av intressenter

Det förra mönstret (mönster 4) handlar om organisationsenheter där en organisationsenhet kan ha en relation till en annan organisationsenhet, enligt en viss regel för en viss tidsperiod.

Alltid när något gäller för organisationer eller organisationsenheter kan man fråga sig om detsamma inte kan gälla för andra typer av intressenter, som till exempel personer. I just detta fall kan man ställ sig frågan: ”Kan en person ha en relation till en organisationsenhet eller till en annan person, enligt viss regel, för en viss tidsperiod?”. Eller motsvarande fråga för organisationer som helhet.

Om vi byter supertypen Organisationsenhet mot Intressent kan vi täcka en vid uppsättning relationer mellan parter, till exempel ledningsrelationer, anställningar och kontrakt.

Vi har emellertid introducerat komplexitet genom att vi nu täcker en mycket större variation i relationer mellan parter än bara mor-dotter-förhållanden. Det krävs regler för att styra vilka parter som kan ingå i vilka relationer.

Det kan vi hantera genom att introducera något i modellen som kan kallas regelplan.

Mönster 6: Relationer styrda av ett regelplan

Vi kan dela upp vår modell i två delar.

  • Operativa planet registrerar de dagliga förhållandena (eller händelserna) i domänen. I detta fall vilka konkreta ansvarsförhållanden som finns i verksamheten
  • Regelplanet håller de regler som styr strukturen i det operativa planet. I detta fall vilka typer av parter det kan finnas och vilka typer av ansvarsförhållanden som kan finnas för varje kombination av två typer av parter.

På så sätt definierar varje förekomst i regelplanet en tillåten konfiguration av förekomster i operativa planet.

Exempel: Ett specifikt ansvarsförhållande (en länk mellan två specifika parter) kan endast skapas mellan parter enligt vad som är angivet i Typ av ansvarsförhållande.

Det är intressant att notera hur det operativa planet speglas i regelplanet. De två planen har liknande men inte identiska relationer. Det operativa planet registrerar de specifika parterna i ett visst ansvarsförhållande medan regelplanet definierar vilka typer av parter som är tillåtna för en viss typ av ansvarsförhållande. Detta är ett typiskt mönster: Flervärd mappning i regelplanet för att visa tillåtna typer för en envärd mappning i operativa planet.

Metadata utrycks nu inte längre bara av entitetsstrukturen utan även av förekomsterna i regelplanet. För att systemet (det vill säga informationssystemet i bred bemärkelse) ska fungera räcker det inte med att implementera modellens struktur (till exempel skapa de tabeller som behövs). Vi måste också instansiera objektförekomsterna i regelplanet. Det vill säga till exempel att populera de tabeller som beskriver vilka parter som kan finnas och vilka relationer varje kombination av dessa kan ingå i. Att instansiera regelplanet innebär att konfigurera systemet, det vill säga verksamheten.

Notera att mappningen från Part till Typ av part ersätter subtypning av Part. Att en mappning definierar en subtyp kallas ibland ”power type”.

När ska detta mönster användas? Vi kan inte undvika att hantera den inbyggda komplexitet som finns inom en domän. Vi kan bara fråga oss vilket mönster som enklast representerar den komplexitet vi behöver hantera. Se upp bara så att detta mönster inte blir ett catch-all för alla typer av relationer mellan två parter.

Om regelplan i modeller 

Det är fruktbart att tänka i begreppen regelplan och operativt plan när man modellerar och att hålla isär dessa grafiskt inom ett ämnesområde. Fast jag skriver aldrig ut termen ”regelplan” utan något i stil med ”Regler för kund” eller ”Produktregler” som rubrik för den delen av ämnesområdet.

Regelplan kan ibland också kallas typplan eftersom de oftast innehåller entiteter vars instanser definierar typer. Det är också ett metaplan rent definitionsmässigt, men jag tycker vi ska undvika namnet ”metaplan”, för begreppet ”meta” är ett alldeles för vitt begrepp, det vill säga att det kan betyda lite vad som helst och kan därmed förvirra mer än det tydliggör. Metadata är ju data om data och det rymmer allt möjligt.

Att skikta en modell – eller vanligare ett ämnesområde inom en modell – på detta sätt är ett mycket kraftfullt sätt att ordna sin domän. Det är inte speciellt känt, men jag hoppas att det härmed sprider sig.  

Var kommer dessa mönster från

Jag har hämtat dessa mönster från Martin Fowlers bok ”Analysis Patterns”, från 1997. Det är bok som inte många känner till, i det närmaste en apokryfisk skrift, som jag menar har ett stort värde. Speciellt vill jag nämna detta med regelplan, vilket jag en gång lärt mig från denna bok, och använt i tjugo år i mina modeller. Det är mer eller mindre nödvändigt för att hantera lite mer komplicerade verksamhetsdelar.

/Peter Tallungs, IRM 

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

Om mönster för informationsmodeller

”När vi gör en informationsmodell brukar vi inte börja med endast ett blankt papper och grundprinciperna inom vårt område. Precis som designers inom andra områden så tillämpar och anpassar vi lösningar som har visat sig användbara tidigare. Utvecklingen och användningen av standardlösningar (”modellmönster”) är en viktig del av informationsmodelleringens praktik.” Detta är ett citat av Graeme Simsion, den australienske författaren till en av de viktigaste böckerna om informationsmodellering ”Data Modeling Essential”.

Repertoarer av mönster

Om jag vill lära mig att spela schack lär jag mig kanske först hur brädet och de olika pjäserna ser ut, sedan hur de får lov att flyttas, därefter att vi turas om att göra våra drag och vad spelet går ut på. Detta tar inte så lång tid att lära sig. Har jag då lärt mig allt som där finns att lära? Nej, knappast, jag har knappt ens börjat! Resten av min resa inom området, från gröngöling till mästare, handlar om mönster. Inte så mycket om enskilda drag, mest om kombinationer av drag. Många kombinationer är kända och namngivna. Andra hittar jag själv fram till och kan dra ess ur rockärmen när så passar.

Det är så det går till inom i stort sett alla områden av mänsklig verksamhet. Både som kollektiv och individer har vi en repertoar av mönster som vi uppfinner, tillämpar, utvecklar och traderar.

Så har vi alltid gjort inom olika områden. Det som jag här benämner mönster kan kallas för en mängd olika saker men det har, i olika sammanhang, blivit mer vanligt att prata om just ”mönster”.

Mönster-begreppet inom informationsmodellering

Inom informationsmodellering har begreppet mönster använts och definierats på följande sätt:

  • Data Model Patterns (Dave Hay)
    ”Common situations that are present in a variety of business and government agencies, and which can be modeled in a standardized way – conventions of thought.”
  • Analysis Patterns (Martin Fowler)
    ”[in object-oriented analysis we] are regularly seeing problems repeat themselves.”
    ”A pattern is an idea that has been useful in one practical context and will probably be useful in others.”
  • Universal Patterns for Data Models (Len Silverston)
    ”The common underlying structures that are applicable to all data models.”
  • Patterns of Data Modeling (Michael Blaha)
  • Patterns and generic models (Graeme Simsion och Graham Witt)

Hur tanken om mönster växt fram och nått området informationsmodellering

Jag har tidigare gjort grafen nedan för att visualisera min tolkning av hur idén om mönster växt fram; från byggnadsarkitektur, via programvaruutveckling till informationsmodellering.

Den som först började tala om mönster i den här meningen var byggnadsarkitekten och designteoretikern Christopher Alexander. Det handlade då om byggnadsarkitektur, allt från stadsplanering till inredningsarkitektur. Hans filosofi har inspirerat många inom olika designdiscipliner, inte minst inom systemutveckling och verksamhetsarkitektur.

Viktigt om mönster

Det finns i några av idéerna formella krav på hur man ska strukturera beskrivningen av ett mönster. De härstammar från Christopher Alexanders idéer om designmönster. De är lite olika men kan se ut så här:

  • Namn
  • Det generella problemet som ska lösas
  • Den generella lösningen
  • Exempel på konkreta lösningar
  • Konsekvenser
  • Samband med andra mönster

Det som ibland har missförståtts, är att mönster inte är ett självändamål. Det var något som hände inom programvaruutveckling efter 1994 när designmönster gjorde sin entré i programmerarvärlden genom boken ”Design Patterns”. Då blev det en sport att klämma in så många som möjligt av bokens designmönster i sin kod.

Christopher Alexanders idé var att alla mönster inom ett område skulle fungera som ett språk för olika designlösningar. Han kallade det ett mönsterspråk (”Pattern Language”). Tanken är att vi tillsammans kan tradera olika lösningar samt diskutera, värdera och tillämpa dessa. Varje mönster har sina styrkor och svagheter, och passar olika bra beroende på sammanhanget. Vi ska inte bara kunna tillämpa mönster utan också välja bort ett mönster när det inte passar.

Mönster för informationsmodeller

Jag kommer i artiklar framöver att presentera ett antal mönster för informationsmodeller. En del av dessa mönster har jag lärt mig från olika böcker och sedan tillämpat i olika sammanhang. (Eller kanske glömt varifrån jag fått inspirationen. Vem kan komma ihåg var man får allt ifrån?) Jag kommer inte att vara så noga med strukturen på beskrivningen, utan min tanke är att grundligt presentera och diskutera varje mönster. I det sammanhanget kommer jag också, när det passar, ta upp andra mer grundläggande frågor runt modellering.

Syftet är att dela kunskap och erfarenheter inom informationsmodellering, samt att inspirera till en dialog runt detta. På så sätt kan vi kanske få igång en utveckling inom vårt kunskapsområde.

Källor för modellmönster

Jag har angivit några av mina källor ovan och jag kommer fortsättningsvis att försöka ange källorna för de mönster jag beskriver. Var har du hittat dina mönster? Har du något tips på en bra källa så tror jag att vi alla som läser detta blir tacksamma.

/Peter Tallungs

I och med denna artikel har vi ett sommaruppehåll. Torsdag 12 augusti kommer nästa artikel i denna serie om informationsarkitektur publiceras.

Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Saker jag stjäl från UML

UMLs klassdiagram har ett par uttrycksmedel som jag saknar i de vanliga ER-notationerna. Det finns inget som hindrar att vi ”lånar” in dessa.

Jag brukar använda den vanligaste notationen för informationsmodeller, det vill säga JMIE (James Martin Information Engineering), kanske mest känd som ”Crow foot notation” (kråkfotsnotation). Främst för att den är vanligast i de sammanhang jag jobbar. Men i den notationen saknar jag ett par saker som finns i UML. Då brukar jag helt sonika låna in dessa.

Ett försvar för att låna från olika notationer

Jag kan tänka mig att en och annan nu sätter kaffet i vrångstrupen bara av tanken på att blanda notationer. Man tycker det är viktigt att vara korrekt, följa regler och att alla gör likadant.

Mitt försvar är att det finns en tid för regler och konsekvens, och det finns en tid för experimenterande och utveckling. Informationsmodellering har som kunskapsområde stått still, i min mening stelnat redan för flera decennier sedan.

Ska vi få till en utveckling av området behöver vi experimentera. Vi behöver vara nyfikna, inspireras från andra områden, kombinera idéer och prova oss fram. Standardisera kan vi vänta med tills vi kommit fram till något som känns någorlunda stabilt. Och dit har vi en bit kvar.

I det följande redovisar jag det jag saknar i vanliga ER-notationer men som finns i UML, och som jag därför fräckt och oblygt lånar in.

Supertyp och subtyp separerade från varandra

Om en entitet är en generalisering av två eller flera andra så ritar man i de vanliga ER-notationerna den generaliserade entiteten (supertypen) som en ram runt de specialiserade entiteterna (subtyperna).

I UML ritar man i stället subtyperna separerade från supertypen, och en relationslinje emellan dessa med en ofylld triangelspets i änden mot supertypen.

(Det finns dock även en del äldre ER-notationer som också separerar super- och subtyp på samma sätt som UML. Relationen kallas då
”is-a”-relation)

Båda ritsätten har sina styrkor och svagheter menar jag.

Fördelen med ritsättet med supertypen som ram är att det intuitivt ger en bättre förståelse för vad det handlar om. Relationen mellan sub- och supertypen är inte en relation mellan två separata företeelser, utan en relation mellan två begrepp, ett mera generellt och ett mera specifikt. En sådan relation har alltså en helt annan natur än de vanliga relationerna som övriga streck representerar. Därför är det bra med ett ritsätt som kraftigt avviker från övriga relationer.

Supertypen är ett mer generellt begrepp för samma företeelser som subtypen. En förekomst av subtypen är samtidigt en förekomst av supertypen. Det finns på så sätt en likhet med de Venndiagram som vi minns från skolans mängdlära. Ritsättet gör att risken minskar att en ovan betraktare av en informationsmodell ska tro att en motorfordonsförsäkring är något annat än en försäkring.

Med UMLs ritsätt är det däremot lätt för en ovan betraktare att tro att vi, precis som med andra typer av relationer, har två olika företeelser med olika förekomster. Där har vi svagheten att relationer med så helt väsensskilda naturer har så lika grafisk gestaltning.

Men det finns också en baksida med ritsättet i JMIE. Det finns tillfällen då det blir omöjligt att rita subtyperna inuti supertypen. Det är när varje subtyp behöver veckla ut sig till ett eget ämnesområde med många egna entiteter runtomkring som är unika för just det ämnesområdet. När det behovet uppkommer ritar jag som i UML, trots att jag i övrigt använder JMIE. Det vill säga sub- och supertyper för sig, förbundna med en linje med en ofylld triangelformad pilspets.  

Komposition

Det är vanligt att två entiteter har en särskilt existentiell koppling. Det vill säga att en förekomst av en entitet inte kan existera oberoende av en förekomst av en annan entitet. Ett exempel är en faktura med en eller flera fakturarader. Relationen mellan faktura och fakturarad innebär en mycket starkare koppling än vanliga relationer. En fakturarad har nämligen ingen självständig existens, den kan aldrig existera utan att tillhöra en faktura, den kan inte byta faktura, och om fakturan raderas så försvinner också fakturaraden. I en del äldre notationer kallas den beroende entiteten för beroendeobjekt. Jag tycker att en informationsmodell blir mycket tydligare om man tydligt kan uttrycka den starka relationen.

I de vanliga ER-notationerna finns det ingen möjlighet att uttrycka detta på annat sätt än med den vanliga min 1 – max 1-symbolen, trots att det är en koppling som är väsensskild från vanliga min 1 – max 1-kopplingar.

I UML kallas den relationen komposition och uttrycks med en romb och en pilspets enligt bild. Egentligen ska romben vara fylld men den symbolen finns inte som standard i Visio så vi får nöja oss med en ofylld.
Inom parentes sagt: Den ofyllda romben uttrycker i UML ett aggregat, vilket i praktiken är samma som en min 1 – max 1-koppling, och därför är tämligen meningslös. Jim Rumbough, en av grundarna till UML, liknade det själv vid placebo och Martin Fowler ägnar en hel uppsats till att avfärda konstruktionen. 

Så fort jag har en relation i ett ER-diagram som har denna täta koppling så markerar jag det med en romb. På så sätt tycker jag att modellen blir tydligare. Man ser då vad som har en självständig existens och vad som är en integrerad del av en annan företeelse. Dessutom brukar jag placera entiteterna med den beroende entiteten placerad under och med vänsterkanten indragen från huvudentiteten, som bilden till höger visar. På så sätt vill jag tydlig signalera det nära och underställda beroendet.

Vilka innovativa idéer har du?

Jag vill med detta inspirera till experimenterande. Att vi kan lösa modellerings- och gestaltningsproblem på ett nyskapande sätt när så behövs. Vi ska inte vara rädda för att göra fel och måste inte alltid ”play by the book”. Ett område kan bara gå framåt när någon med ett tydligt syfte bryter mot ingrodda regler och ”sanningar”. Den lilla risken vi får ta är att våra modeller därmed blir lite brokigare. Men det är ett lätt pris om det kan bidra till att avancera hela vårt område.

Nu är det din tur. Vad brukar du göra annorlunda?

/Peter Tallungs

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 24 juni. Då handlar det om mönster för informationsmodeller.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.